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Chapter  I 


INTRODUCTION 

The  Comparative  Prediction  Methodology  for  Decentralized  DDBMS  program, 
to  be  called  'effort*  in  this  report,  was  undertaken  to  prepare  a  3et  of 
software  programs  that  can  serve  multiple  purposes.  This  report  gives  a 
status  snapshot  of  that  effort  3t  the  end  of  a  12  month  period.  Once 
the  preliminary  reviews  of  the  scope  of  the  program  were  completed  it 
was  obvious  that  the  final  objectives  of  the  proposal  could  not  be  com¬ 
pletely  obtained  in  the  one  year  that  was  allotted.  However,  it  is  the 
contention  of  the  investigators  that  a  considerable  step  toward  the  end 
goal  has  been  attained. 

As  described  in  the  proposal,  two  clearly  defined  and  separate  areas 
of  interest  were  to  be  investigated,  the  developnent  of  a  programming 
package  that  eould  serve  as  support  and  background  for  the  simulation  of 
distributed  systems,  and  the  developnent  of  a  model  for  the  simulation 
of  the  Concurrency  Control  Algorithm  of  the  SDD-1  system.  The  two  sec¬ 
tions  indeed  run  as  a  single  program.  However,  the  Distributed  System 
Simulator  (DISS)  package  is  a  generalized  support  aid  for  the  simulation 
of  a  wide  range  of  distributed  system  models  and  is  3  stand  alone  sup¬ 
port  package.  It  is  designed  to  work  with  any  algorithmic  description 
that  converses  satisfactorily  with  the  DISS  package.  There  are  of 
course  a  set  of  rules  that  must  be  obeyed  when  designing  the  distributed 
system  model  so  that  the  two  major  sections  interface  correctly  3nd  thus 
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mutually  support  each  other.  The  second  software  section  developed  is  a 
model  of  the  SDD-1  Concurrency  Control  Algorithm.  This  model  has  been 
designed  to  operate  with  the  DISS  package  and  is  now  in  operation.  All 
programs  were  written  in  the  Simscript  II. 5  programming  language 
(Russ73) • 

This  report  contains  a  more  detailed  review  of  the  two  programming 
sections  in  Chapters  II  and  III.  The  Concurrency  Control  Monitor 
designed  for  the  Algorithm  is  discussed  in  chapter  IV.  A  description  of 
the  Performance  Measurements  planned  for  the  model  and  the  Performance 
Evaluation  is  given  in  Chapters  V  and  VI.  The  conclusions  and  recommen¬ 
dations  are  presented  in  Chapter  VII. 
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Chapter  II 


THE  DISTRIBUTED  SYSTEM  SIMULATOR 

Repeated  generation  of  simulation  models  representing  queues  and  ser¬ 
vers,  computer  systems,  computer  operating  systems,  and  distributed  sys¬ 
tems  has  led  to  the  concept  of  designing  a  generalized  model  that  can  be 
used  as  a  basis  by  a  large  family  of  applications.  The  areas  mentioned 
and  especially  the  subject  of  distributed  computer  networks  today  offer 
sufficient  common  simulation  requirements  to  warrant  the  formulation  of 
a  general  framework  within  which  one  can  modularly  model  a  particular 
system. 


The  Distributed  Network  Simulator,  (DISS),  package  was  designed  to 
allow  the  modeler  to  concentrate  his  efforts  on  the  unique  algorithmic 
aspects  of  the  system,  and  release  him  from  preparing  the  standard 
repetitive  elements  of  a  simulation  experiment  of  a  distributed  system 
model.  Such  an  approach  reduces  the  time  of  the  model  design  period  and 
of  the  amount  of  code  required  to  prepare.  At  the  same  time  this  method 
offers  a  broad  range  of  organization  options  and  performance  measurement 
features.  A  simulation  experiment  using  DISS  comprises  two  major  sec¬ 
tions  when  in  execution,  a)  a  modeler  supplied  set  of  processes  and 
operating  parameters  and  b)  the  fixed  background  framework. 
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The  user  supplied  material  describes  the  network  characteristics  such 
as  configuration,  operating  conditions,  node  specifications  3nd  other 
applicable  details  that  are  peculiar  to  this  model.  The  concept  of  a 
node  is  left  to  the  modeler  and  can  represent  a  simple  control  element 
or  a  complete  independent  system.  The  user  supplies  a  process  descrip¬ 
tion  of  each  unique  type  of  node  that  is  incorporated  into  the  network. 
The  processes  are  the  modular  elements  of  the  system.  The  process  con¬ 
tains  all  algorithmic  descriptions  of  the  tasks  implemented  by  the  node 
including  the  initialization  of  communications  with  other  elements  of 
the  network.  The  user  must  also  supply  all  the  necessary  parameters 
required  for  the  simulation  runs,  and  the  output  options.  The  pro¬ 
cesses  that  are  prepared  mu3t  contain  the  necessary  interfaces  to  the 
background  framework  in  order  to  establish  the  simulation  structures 
required.  These  structures,  based  upon  local  nodal  parameters,  then 
belong  to  the  particular  node. 

The  background  framework  has  been  developed  to  meet  the  general  simu¬ 
lation  needs  of  a  wide  range  of  distributed  system  problems  that  can  be 
represented  as  directed  graphs.  From  the  network  input  information  the 
configuration  and  the  nodal  relationships  are  established.  The  nodes 
are  initiated  by  the  background  routines  that  supply  the  necessary  simu¬ 
lation  structures  required  for  the  runs.  These  include  the  establish¬ 
ment  of  the  measurement  facilities  offerred  by  the  programming  language 
and  requested  by  the  individual  node  as  required. 


In  addition  to  the  standard  automatic  statistics  collecting  features 
of  the  language  the  user  may  call  upon  DISS  routines  that  supply  confi¬ 
dence  intervals  and  autocorrelation  data  for  selected  variables.  The 
package  also  contains  a  sophisticated  tracing  routine  that  permits  a 
detailed  step  by  step  reporting  of  system  conditions  3S  specified  by  the 
modeler  and  is  intended  for  debugging  and  verification  purposes. 

A  more  detailed  and  complete  description  of  DISS  appears  in  Appendix 
A  as  a  self  contained  report.  This  report  was  submitted  and  will  appear 
in  the  Proceedings  of  the  Summer  Computer  Simulation  Conference  that  is 
to  take  place  on  July  19-21,  1932  in  Denver,  Colorado.  Reference  mater¬ 


ial  for  the  DISS  package  is  found  in  Appendix  A. 


Chapter  III 


CONCURRENCY  CONTROL  ALGORITHM 

3.1  INTRODUCTION 

A  distributed  multiple  copy  data  base  management  system  represents  a 
complex,  highly  sophisticated  mechanism  (Bern78,  Bern79a,  Bern79b, 
BernBOa,  BernBOb,  RothBO) .  The  common  denominator  of  all  data  base  sys¬ 
tems  is  that  users  enter  queries  in  an  attempt  to  retreive  information 
or  to  update  the  information  maintained  in  the  data  base.  If  one  is  to 
model  a  specific  feature  of  a  certain  type  of  system,  it  is  necessary  to 
analyze  the  system  to  determine  those  features  that  are  common  to  the 
entire  family  of  systems  and  the  features  that  are  unique  to  the  parti¬ 
cular  system  of  interest.  It  is  then  sufficient  to  model  only  those 
features  that  are  peculiar  to  the  system  of  interest  and  to  ignore  the 
common  operations.  This  chapter  reviews  those  features  of  a  distributed 
multiple  copy  data  base  system,  selects  those  features  that  are  directly 
involved  with  the  concurrency  control  and  finally  presents  the  model  for 
the  simulation  of  the  algorithm. 

3.2  A  COMPLETE  SYSTEM 

A  generalized  data  base  system  can  be  characterized  by  tne  following 
sequential  operations  that  3re  carried  out  to  meet  the  needs  of  the 
user : 

1.  Arrival  of  queries 
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2.  translation  of  queries  to  determine  the  exact  requirement  of  the 
user 

3.  Determine  the  best  location  of  the  desired  data  and  retrieve  the 
data.  This  may  involve  large  sorting  operations  depending  upon 
the  data  base  organi zation ,  the  system  architecture  and  the 
nature  of  the  query. 

4.  Compilation  of  the  query  commands  to  perform  the  required  opera¬ 
tions  on  the  retrieved  data. 

5.  Execution  of  these  operations  at  the  locations  of  the  retrieved 
d3ta  and  then  joining  the  partial  results  to  form  the  final 
results . 

6.  Presentation  of  these  final  results  to  the  user,  if  requested. 

7.  Updating  the  data  base  with  the  corrected  data  as  requested. 

If  the  dat3  base  is  distributed  over  several  sites,  has  multiple 
copies  of  the  data  base  fragments,  has  multiple  entry  for  queries  and 
has  no  central  control  but  has  a  local,  cooperating,  autonomous  control 
for  the  execution  of  the  queries  at  each  site  then  the  sequencing  of  the 
execution  of  the  queries  in  order  to  maintain  the  consistency  of  the 
data  base  presents  a  serious  problem.  The  basic  requirement  for  global 
data  consistency  remains.  This  development  program  has  been  involved  in 
the  construction  of  a  model  of  an  algorithm  that  guarantees  data  base 
consistency  when  the  data  base  is  distributed  with  redu.ident  copies  of 


selected  fragments  of  the  data  base.  These  algorithms  are  call  Concur¬ 
rency  Control  Algorithms.  Recently,  two  complete  families  of  concur¬ 
rency  control  algorithms,  Two-Phase  Locking  (ManaBO),  and  Timestamp  Ord¬ 
ering  (Thom79),  have  been  reported  (BernBI). 

This  effort  has  concerned  itself  with  the  Conservative  Timestamp  Ord- 
erering  algorithm  associated  with  the  SDO-1  program.  In  modeling  such 
an  algorithm  for  the  type  of  data  base  required,  the  question  is  how 
much  of  the  system  operation  is  actually  required  to  be  modeled.  Model¬ 
ing  an  algorithm  to  determine  its  cost  and  efficiency  can  be  interesting 
only  if  the  performance  results  of  the  model  may  be  compared  with  those 
of  another  competing  algorithm  running  under  similar  conditions.  The 
cost  of  implementing  an  algorithm  is  therefore  reduced  to  all  system 
delays  that  can  be  directly  charged  to  the  algorithm.  In  a  data  base 
system  this  can  be  interpreted  as  meaning  the  co3t  of  the  communications 
required  by  the  algorithm  and  any  additional  delays  determined  by  the 
implementation  of  the  algorithm.  But  most  important,  it  means  that  the 
cost  of  the  data  base  operations  common  to  all  systems,  mentioned  in 
section  1  of  this  chapter  may  be  ignored. 

3.3  SYSTEM  MODEL 

The  system  model  designed  permits  the  modeler  complete  freedom  in  deter¬ 
mining  the  system  topology  anJ  the  structure  of  the  data  base.  The 
model  a3  designed  contains  a  system  of  10  nodes,  made  up  of  five  TMs  and 
five  DM3.  The  Data  base  is  structured  with  11  fragments  randomly  spread 
over  the  five  DM3  with  a  maximum  of  seven  fragments  at  a  single  node. 
This  permits  for  considerable  replication  of  the  fragments.  Five  tran- 


saction  classes  are  defined  executing  PI,  P2  and  P3.  The  five  classes 


each  have  an  allowable  read-set  and  write-set  consisting  of  selected 
fragments,  in  keeping  with  the  conflicting  class  concept.  When  new 
transactions  arrive  at  a  class,  each  selects  a  random  number  of  read  and 
write  fragments,  up  to  the  maximum  number  assigned  to  that  class  and 
then  randomly  selects  the  particular  fragments.  No  duplications  within 
a  set  are  possible. 

The  transactions  execute  all  of  the  possible  communications  as 
required  by  the  SDD-1  system  algorithm  and  these  time  delays  are  charged 
as  part  of  the  SDD-1  cost.  Table  1  represents  the  message  pattern  of 
the  system. 


TABLE  1 


System  Messages 


Msg 

.  From 

To 

Purpose 

1 

TM 

Read  DMs 

READ 

2 

Read  DMs 

TM 

READ  Complete 

3 

TM 

Read  DMs 

EXECUTE 

4 

Read  DMs 

FINAL  DM 

Partial  Results 

5 

FINAL  DM 

TM 

EXECUTE  Complete 

6 

TM 

FINAL  DM 

Start  UPDATE  Distribution 

7 

FINAL  DM 

UPDATE  DM 

UPDATE  Distribution 

3 

Update  DM 

FINAL  DM 

Secure  Memory  Update  Complete 

9 

FINAL  DM 

TM 

Phase  I  Update  Complete 

10 

TM 

WRITE  DMs 

Phase  II  Write 

11 

TM 

DM 

Periodic  NULLWRITE 

12 

DM 

TM 

Request  for  NULLWRITE 

13 

TM 

DM 

NULLWRITE  in  response  to  req. 

14 

Read  DM 

TM 

READ  Rejected 

3.4  MODEL  FOR  THE  SDD-1  CONCURRENCY  CONTROL  ALGORITHM 
The  model  designed  for  the  SDD-1  Concurrency  Control  Algorithm  is  based 
upon  the  use  of  the  DISS  package  described  in  the  previous  chapter.  In 
keeping  with  the  DISS  discipline  three  processes  were  designed,  an  Exe¬ 
cution  Manager  (EM),  a  Transaction  Manager  (TM),  and  a  Data  Manager 
(DM).  The  TM  and  DM  processes  are  fashioned  after  the  suggested  process 
design  of  the  DISS  package.  As  described  in  the  DISS  report  in  the 
Appendix,  a  nodal  process  is  characterized  by  the  External  Alert  Func¬ 
tions,  the  Internal  Alert  Functions  and  by  the  Termination  Function  exe¬ 
cuted  by  the  process. 

3.4.1  TM 

The  generalized  TM  Process  executes  the  following  functions: 

3. 4. 1.1  External  Alert  Functions: 


1. 

Read  Complete 

msg.  no.  2 

2. 

Transaction  Rejection 

msg.  no.  14 

3. 

End  of  Execution 

msg.  no.  5 

4. 

End  of  Update  Distribution 

msg.  no.  9 

5. 

Request  for  a  Nullwrite 

msg.  no.  12 

10  - 


3. 4. 1.2  Internal  Alert  Functions: 


1.  End  of  Message  Transmission 

2.  Send  Periodic  Nullwrite  msg.  no.  11 

3.  Arrival  of  New  Transaction 


3. 4. 1.3  Termination  Alert  Function 


3.4.2  DM 

The  generalized  DM  Process  executes  the  following  Functions: 


3.4.2. 1  External  Alert  Functions: 


1 . 

Arrival 

of 

Nullwrite 

msg. 

no. 

13 

2. 

Arrival 

of 

Write 

msg . 

no. 

10 

3. 

Arrival 

of 

Read 

msg. 

no. 

1 

Functions  1,  2,  and  3  share  in  the  use  of  the  SCAN  procedure. 
The  three  functions  and  SCAN  implement  the  Concurrency  Control 
Algorithm. 

4.  Execute  msg.  no.  3 

5.  Partial  Results  Arr.  Final  DM  msg.  no.  4 

6.  Start  Distribution  msg.  no.  6 

7.  Phase  1  Update  msg.  no.  7 


8.  End  of  Phase  1  Update 


msg.  no.  8 


3. 4. 2. 2  Internal  Alert  Functions: 

1.  End  of  Message  Transmission 

2.  End  of  Access  to  Data  Base 

3.  Timeout  Request  for  Nullwrite 


3. 4. 2. 3  Termination  Alert  Function 


3.4.3  EM 

The  Execution  Manager  process  is  designed  to  execute  its  required  func¬ 
tions  in  a  sequential  manner  so  as  to  manage  the  complete  experiment 
from  start  to  finish.  The  following  is  a  list  of  these  functions: 

1.  Initialization  and  file  control 

2.  Network  Establishment 

3.  Network  Topology  printout 

4.  Experiment  Control  Parameter  input 

5.  Data  Base  Definition 

6.  Node  Establishment 
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7.  Simulation  Control 


8.  Schedule  of  Termination  Function  for  all  nodes 

9.  Log  Printout 

13.  Release  structures 

11.  End 
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Chapter  IV 


THE  CONCURRENCY  MONITOR 

The  order  of  accepting  and  processing  requests  for  Data  Access  (DA)  at 
any  DM  is  assumed  not  to  violate  the  rules  mentioned  in  the  SDD-1  refer¬ 
ences.  A  scheduling  mechanism  at  each  DM,  called  the  Concurrency  Moni¬ 
tor,  is  responsible  for  this  ordering. 

4.1  STRUCTURES  USED  BY  THE  CONCURRENCY  MONITOR 

In  the  SDD-1  system  each  READ  massage  carries,  among  other  things,  a 
list  of  conflicting  classes  .  The  simulated  model  uses  a  global  matrix 
to  store  conflicting  classes  instead  of  sending  them  with  the  read  mes¬ 
sage.  Each  DM  maintains  a  Concurrency  Table  ( CT)  ranked  by  class  num¬ 
ber.  As  can  be  seen  from  the  Table  2,  The  CT  contains  two  columns.  The 
first  column  stores  the  timestamp  of  the  most  recently  processed1  WRITE 
request.  The  second  column  stores  the  timestamp  of  the  most  recently 
processed  NULL'WRITE  message. 

For  each  class  I,  a  queue  for  messages  called  Concurrency  Monitor 
Queue  of  I,  CMQ(I),  and  a  set  for  unmet  read  conditions  called  Con¬ 
flicting  Classes  Read  Coditions  (CC.RC(D)  are  created  at  each  DM.  Upon 
arrival,  WRITE  messages,  NULLWRITE  messages,  and  accepted  READ  messages 
are  filed  last  in  the  correspon J ing  CMQ.  Messages  are  removed  from  the 
CMQs  only  at  the  moment  they  C3n  access  the  local  dat3  base.  The  first 


Submitted  to  the  lata  access  queue  but  not  necessarily  completed. 
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TABLE  2 


Concurrency  Table 

Timestamp  of  Timestamp  of 
most  recently  most  recently 
processed  processed 


!  Class  WRITE  NULLWRITE  ! 

I  I 

» _ _ _  » 

I  I 

I  I 

!  1  34527  34632  i 

!  2  33674  33935  ! 

I  I 

I  I 

I  l 

I  I 

I  I 

I  I 

4-- - 4* 


member  in  each  CMQ  is  called  Immediately  Pending  (IP).  If  the  IP  mes¬ 
sage  in  CMQ(I)  is  a  READ  with  some  unsatisfied  read  conditions,  then, 
for  each  unmet  read  condition,  a  member  identifying  the  class  for  which 
the  condition  is  not  net,  is  filed  in  the  set  of  CC.RC(I).  A  member  is 
removed  from  CC.RC(I)  whan  the  class  it  points  too,  fulfills  the  read 
condition . 

*  Access  to  the  local  database  is  through  the  Data  Access  (DA)  queue 
which  is  a  3imple  fifo  queue. 

4.1.1  Concurrency  Monitor  Priorities 

Concurrency  Monitor  requests  for  dat3  access  is  male  at  the  DM  by  a  low- 
priority-first  mechanism.  Each  IP  message  is  given  a  PR  number  which 
defines  it's  priority.  The  PR  of  a  WRITE  or  a  NULLWITE  is  simply  it's 
TS.  For  establishing  the  priority  of  an  TP  READ  message,  three  cases 


are  considered: 


1.  If  all  read  conditions  for  the  READ  are  met,  PR  is  the  read  tim- 
stamp  TSR. 

2.  Not  3ll  read  conditions  are  met  and  no  WRITE  or  NULLWRITE  message 
is  pending  in  the  CM3  of  any  conflicting  class  which  doesn't  meet 
the  read  condition.  In  that  case  PR  is  also  the  TSR  associated 
with  the  message. 

3.  Not  all  read  conditions  are  met  and  at  least  one  conflicting 
class  with  unmet  read  condition  has  a  WRITE  or  NULLWRITE  pending 
in  it's  CMQ.  In  this  case  the  PR  is  the  lowest  TS  among  the 
WRITES  or  NULLWRITE?  pend.ng  in  the  CMQ's  of  the  conflicting 
classes  with  unsatisfied  read  conditions. 

Scheduling  is  done  by  lowest  priority  first  except  for  one  case  which 
will  be  discussed  below. 

4.2  ARRIVAL  OF  A  READ 

An  arriving  READ  massage  is  first  checked  to  see  if  it  is  immediately 
rejectable.  A  READ  mu3t  be  rejected  only  if  a  WRITE  from  a  conflicting 
class  with  TS  greater  then  the  read  timestamp  TSR  was  already  processed. 
The  information  in  the  CT  is  used  for  this  check.  In  case  of  a  rejec¬ 
tion,  a  READ  REJECTED  message  is  sent  to  the  supervising  TM.  The  TM 
retries  the  Transaction  READ  operation  up  to  10  times  before  abandoning 
the  Transaction.  If  READ3  are  distributed  among  several  DMs,  those 
READ3  that  are  not  -ejected  must  be  cancelled.  The  TM  assigns  a  new  TS 
for  each  new  retry  until  the  cause  of  the  rejection  is  eliminated.  An 
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accepted  READ  Is  filed  last  in  the  corresponding  CMQ  and  if  it  is  IP, 
read  conditions  are  checked,  PR  is  calculated  and  a  SCAN  procedure, 
dicussed  later  in  this  section,  is  called. 

4.3  ARRIVAL  OF  A  WRITE 

WRITE  messages  are  never  rejected.  A  new  WRITE  from  class  I  called 
Wi(I)  has  just  ARRIVED.  If  no  other  WRITE  or  NULLWRITE  precedes  Wi(I) 
in  CMQ(I)  then  the  read  condition  and  the  PR  for  each  IP  READ  with  class 
I  as  an  unsatisfied  read  condition  is  checked.  Assume  that  I  is  in  J's 
set  of  conflicting  classes  and  there  is  an  IP  READ  called  Rj(J)  in 
CMQ(J).  The  PR  of  Rj(J)  is  PRj  and  it's  TSR  is  TSR j .  The  TS  of  Wi(I) 
is  TSi .  Three  cases  are  considered: 

1.  TSi  <  PRj.  The  new  WRITE  has  a  lower  timestamp  than  the  one  that 
previously  determined,  PRj.  PRj  is  set  to  TSi  and  the  read  con¬ 
ditions  are  not  changed. 

2.  PRj  <  TSi  <  TSRj  .  No  correction  is  needed.  Wi(I)  does  not  ful¬ 
fill  the  read  condition  of  Rj(J)  and  TSi  is  not  the  lowest  times¬ 
tamp  in  the  unsatisfied  read  conditions  of  Rj(J). 

3.  TSRj  <  TSi  .  WiCI)  satisfies  the  condition  of  Rj(J).  The  member 
specifying  I  as  an  unmet  condition  is  removed  from  CC.RC(J). 

If  a  modification  is  made  to  any  IP  READ  or  if  Wi(I)  is  IP  in  CM3(I), 
the  SCAN  procedure  is  be  called. 
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4 . 4  ARRIVAL  OF  A  NULLWRITE 

Since  more  then  one  N'JLLWRITE  can  carry  the  same  timestamp,  new  NULL- 
WRITES  are  ignored  if  a  N'JLLWRITE  with  the  same  timestamp  already  exists 
or  was  processed.  Otherwise  .the  same  procedure  as  for  3  new  WRITE,  is 
performed  for  the  new  NULLWRITE. 

4.5  SCANING  THE  IP  MESSAGES 

Whenever  a  change  is  made  to  an  IP  message,  the  SCAN  procedure  i3 
called.  SCAN  is  responsible  for  transferring  DA  requests  from  the  CMQ3 
of  a  particular  Did  to  the  DM's  DA  queue.  The  transfer  is  made  as  soon  as 
possible  and  without  indefinitly  postponing  any  request  (BernSOb). 

As  a  first  step,  IP  messages  at  the  DM  are  scanned  for  the  minimum 
priority,  MIN. PR.  No  two  IP  WRITES  or  two  IP  NULLWRITE3  or  IP  WRITE  and 
IP  NULLWRITE  can  have  the  same  PR.  This  is  true  because  their  PRs  are 
equal  to  their  TSs  and  messages  from  different  classes  can  not  have  the 
same  TS  (a  WRITE  and  a  NULLWRITE  from  the  same  class  can  have  the  same 
TS  but  can't  be  both  IP).  The  problem  is  that  there  can  be  a  single  IP 
WRITE  or  IP  NULLWRITE  and  one  or  more  IP  READs,  all  having  the  same 
MIN. PR.  This  situation  can  occur  when  for  all  those  READS  the  WRITE  (or 
NULLWRITE)  is  the  unsatisfied  read  condition  with  the  lowest  timestamp. 
If  this  is  the  case,  the  WRITE  (or  NULLWRITE)  is  taken  as  the  MIN. PR. 
When  more  than  one  message  has  the  same  MIN. PR,  but  all  of  them  are  IP 
READ3,  one  of  them  is  taken  as  the  MIN. PR. 

A  simple  low  priority  first  mechanism  has  some  potential  deadlocks. 
One  of  the  potential  deadlocks  is  discussed  in  (McleSI).  As  an  example 

». 
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of  a  situation  that  oan  cause  that  kind  of  deadlock,  consider  a  system  j 

with  two  classes,  I  and  J.  I  is  in  conflict  with  J  and  J  is  in  conflict  I 

with  I.  There  are  only  two  transactions  in  the  system,  i  in  I  and  j  in  j 

| 

J.  Each  transaction  sends  it's  READ  to  a  different  DM  and  waits  there  \ 

i 

for  the  other  class  to  satisfy  the  read  condition.  Since  no  transaction 

can  process  and  no  DM  can  detect  the  deadlock,  this  deadlock  can't  be  \ 

broken  unless  NllLLVfRITES  3re  sent.  In  the  simulated  algorithm  a  READ  * 

that  has  reached  the  point  of  MIN .  PR  and  can  not  fulfill  all  of  it's 
read  conditions  for  a  timeout  period  causes  the  request  of  a  NULLV/RITE 
message  for  each  unmet  read  condition. 

A  second  potential  deadlock  is  described  in  (BernSDb)  It  arises  in 

i 

the  above  situation  when  the  READs  arrive  at  the  same  DM.  It  can  easily 
be  seen  that  no  special  action  must  be  taken  in  addition  to  N'JLLWRITE 
request.  The  deadlock  breaking  iesoribei  in  (Bern3Db)  is  not  needed  and 
will  not  help  solve  the  problem  in  the  system  considered  here. 

I 

I 


The  third  type  of  deadlock  actually  occured  in  the  model  discussed 
here.  As  3n  example  consider  a  system  with  three  classes  of  transac¬ 
tions,  I,  J  and  K.  The  conflict  graph  caused  by  their  re3i  and  write 
sets  is  shown  in  Figure  1.  As  can  be  seen  from  this  graph,  class  J  runs 
PI  against  class  I  and  classes  I  and  K  run  P3  against  each  other.  Only 
two  transactions  exist  in  the  system,  i  in  I  and  j  in  J.  Their  times¬ 
tamp  order  is  TSj  >  TSRj  >  TSi  =TSRi  .  The  read  messages,  Ri  and  Rj , 
are  sent  to  the  same  DM.  RJ  arrives  first  and  requests  a  NULLWRITE  from 
TMi  (the  TM  supervising  class  I).  As  Ri  arrives  it  becomes  the  MIN.  PR 
(PRi  =  TSi)  and  requests  a  NULL. JR IT E  from  TM< .  Meanwhile  the  NULLWRITE 
message  from  TMi  arrives  carrying  a  timestamp  which  is  equal  to  TSi.  Ri 
and  Rj  have  the  sane  priority.  Assume  Rj  is  selected  to  be  the  MIN. PR 
message.  Rj  will  remain  3S  the  MIN. PR  until  the  TMi  NULLWRITE  will  be 
processed.  The  TMi  NULLWRITE  cannot  be  processed  until  Ri  will  be  pro¬ 
cessed  and  Ri  cannot  be  processed  bec3u.se  it  is  not  the  MIN.  PR  message. 
A  deadlock  situation  exists. 

The  next  example  of  the  third  type  of  deadlock  is  more  general .  Let 
class  I  be  in  the  set  of  conflicting  classes  of  J,  so  J  must  perform  PI 
against  I.  Three  transactions  are  considered,  i  and  i'  in  class  I  and  j 
in  J.  Their  timestamp  order  is  TSi  <  Tsj  <  TSi'  and  for  simplicity 
assume  that  for  each  one  of  them  TSR  =  T3.  Assune  that  i  arrived  first 
in  the  system  and  it's  Ri  (read  message)  found  an  idling  DM.  Clearly  i 
can  accomplish  it's  read  and  execution  phases.  Meanwhile,  j  enters  the 
system  and  it’s  Rj  reaches  some  DM,  say  DMk .  Rj  can  not  be  processed 
because  it's  read  condition  I  is  not  satisfied.  Transaction  i'  presents 
itself  at  TM(I)  before  i  has  finished  its  execution  phase.  If  Ri ' 
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doesn't  conflict  with  Mi,  TM(I)  can  send  Ri  ’  without  waiting  for  the 
completion  of  i.  Assume  that  Ri *  is  sent  to  DMk.  Ri'  is  IP  and  has 
no  read  condition  to  meet,  so,  it  could  have  read  but  it  is  not  the 
MIN. PR  message  at  DMk.  Tnerefore  Ri '  will  wait  until  Rj  will  be  removed 
from  the  CMQ.  Transaction  i  now  sends  Mi  to  DMk  where  Mi  is  filed  after 
Ri'  in  CMQ(I).  As  a  result,  the  priority  PRj  of  Rj  is  lowered  to  TSi  so 
Rj  still  has  the  MIN. PS.  After  a  timeout  period  Rj  will  request  a  NULL- 
WRITE  from  TM(I).  The  latest  timestamp  this  NULLWRITE  oan  carry  back  is 
TSi'  which  is  large  enough  to  satisfy  the  read  condition  of  Rj'.  Unfor¬ 
tunately  Mi  is  still  pending  in  the  CMj(I)  and  filing  the  N'JLLWRITE 
after  Wi  will  not  do  any  good.  On  the  other  hand,  moving  it  to  the  head 
of  CMQ(I)  as  suggestsd  in  (BernSOb)  will  violate  the  write  pipelining 
rule,  therefore  it  is  forbidden. 

To  avoid  this  kind  of  deadlock,  one  more  scheduling  rule  is  needed: 
If  the  IP  message  with  the  minimum  priority  MIN. PR  is  a  READ  (Rj)  whose 
lowest  priority  unsatisfied  read  condition  is  a  message  from  class  I, 
Mi,  with  TSi,  then.  Mi  is  moved  to  the  head  of  CM3(I),  and  processed 
immediately.  According  to  the  rules  for  calculating  the  PR  of  a  READ, 
Mi  can  be  a  WRITE  or  a  NULLWRITE  but  not  a  READ  message.  Clearly  Mi  is 
not  IP  since  it's  priority  is  equal  to  the  MIN. PR  but  it  was  not 
selected  as  the  MIN. PR  message.  It  is  also  easily  seen  that  only  READ3 
can  be  ahead  of  Mi  in  CMQ(I).  A  WRITE  (or  NULLWRITE)  preceding  Mi  in 
CMQ(I)  must  have  a  lower  PR  contradicting  the  choice  of  Mi  as  the  lowest 
priority  unsatisfied  read  condition.  If  Mi  is  a  NULLWRITE,  processing 
it  before  it's  preceding  READs  will  not  effect  those  READs  because  Mi 
will  not  make  any  change  in  the  data  base  files.  If  Mi  is  a  WRITE,  the 
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READS  preceding  it  belong  to  transactions  that  will  write  after  Mi, 
therefore  they  must  have  later  timestamps.  Tnose  READs  would  not  have 
been  released  from  TM(I)  unless  they  didn't  conflict  with  i's  WRITE  mes¬ 
sage  Mi.  So,  processing  Mi  first  will  not  change  data  items  needed  for 
those  READs. 

Accompanied  by  the  previous  rule  the  correctness  of  the  lowest- 
priority-first  scheduler  can  be  shown.  Let  M  be  the  message  with  the 
lowest  priority.  If  M  is  a  NULLWRITE  it  can  be  processed  immediately. 
NULLWRITEs  are  not  held  by  READs  and  must  obey  only  the  write  pipelining 
rule.  If  M  is  a  WRITE  it  will  be  held  only  by  an  IP  READ  with  a  read 
condition  that  has  a  timestamp  smaller  than  M,  contradicting  the  choice 
of  M.  Therefore  the  WRITE  can  be  immediately  processed  (BernROb).  If  M 
is  a  READ,  three  situations  must  be  checked: 

1.  All  read  conditions  are  met:  The  READ  can  immediately  be  pro¬ 
cessed  . 

2.  Not  all  read  conditions  3re  met  and  there  exists  a  pending  mes¬ 
sage  called  Mi  which  is  M's  unmet  read  condition  with  the  lowest 
timestamp.  This  i3  the  situation  in  which  the  extra  rule  is 
invoked  and  Mi  will  be  passed  to  the  head  of  CMQ(I)  and  become 
the  MIN. PR. 

3.  Not  all  read  conditions  are  met  but  no  pending  WRITE  or  NULLWRITE 
exist  in  any  CM3  of  any  unmet  read  condition.  For  each  unmet 
read  condition  a  WRITE  or  NULLWRITE  will  eventually  arrive. 


Assume  Mi  arrived.  If  I  is  the  last  unmet  read  condition  in  M 
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and  Mi  satisfies  this  condition,  case  1  exists.  If  Mi  satisfies 
I's  condition  hut  M  still  has  other  un-net  read  conditions,  this 
case  remains.  If  it  does  not  satisfy  I's  read  condition  case  two 
exists.  Since  there  are  only  a  finite  number  of  timestamps  smal¬ 
ler  than  TSR  of  M,  eventually  case  one  will  exists. 


After  each  pass  of  SCAN,  a  message  is  chosen.  This  message  is  called 
M.  M  can  be  a  READ,  WRITE  or  NULLWRITE  and  for  each  type  different 
actions  are  taken. 

1.  M  is  a  WRITE:  M  can  be  immediately  transferred  from  the  CMQ  to 
the  DA  queue.  In  addition  the  following  operations  are  per¬ 
formed  . 

a)  The  TS  of  M  must  replace  the  most  recently  processed  WRITE 
timestamp  stored  in  the  Concurrency  Table  ( CT)  in  the  row  cor¬ 
responding  to  M's  class, 

b)  For  each  IP  READ  which  M  is  it's  lowest  priority  unsatisfied 
read  conditions,  recalculate  the  PR  and  check  the  read  condi¬ 
tions  after  removing  M  from  it's  CMQ. 

c)  If  after  removing  M  from  it's  CMQ  the  IP  message  in  that  CMQ 
is  a  READ,  calculate  the  PR  and  set  the  read  conditions  for 
that  READ. 

2.  M  is  a  NULLWRITE:  The  NULLWRITE  is  treated  as  a  WRITE  with  two 
exceptions.  First,  the  NULLWRITE  is  destroy!  after  being  removed 
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from  the  CM3  since  it  Josn’t  access  the  iata.  Second,  it's  TS  is 
stored  in  the  most  recently  processed  NULLWRTTE  column  in  the  CT. 

3.  M  is  a  READ1  If  not  all  read  conditions  for  M  are  satisfied  M 
will  remain  in  the  CMQ  and  the  scheduler  will  wait  for  further 
information.  Otherwise,  the  READ  can  access  the  data.  It  will  be 
removed  from  the  CMQ  and  filed  in  the  DA  queue.  In  addition,  if 
the  IP  message,  after  removing  M  from  the  CMQ,  is  a  READ,  it's  PR 
is  calculated  and  it's  read  conditions  are  set. 

If  any  modification  was  made  during  the  SCAN  pass,  another  pass  of  SCAN 
is  called . 

The  DA  queue  is  a  FIFO  queue  with  a  single  server.  The  average  time 
needed  for  one  access  is  an  internal  parameter  at  each  DM  and  it  can  be 
fixed  through  the  input  information  of  the  DM.  Access  time  is  exponen¬ 
tially  distributed  around  this  average.  When  a  READ  message  ends  data 
access,  a  READ-ENDED  message  is  sent  to  the  supervising  TM.  If  a  WRITE 
ends  its  data  access  a  check  is  male  to  see  if  this  is  the  last  WRITE 
message  for  the  transaction,  and  if  so,  the  transaction  is  destroyed. 

A  block  diagram  describing  the  SCAN  procedure  is  given  in  Appen- 
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PERFORMANCE  MEASUREMENTS 

The  model  developed  for  the  SD3-1  Concurrency  Control  Algorithm  charges 
time  delays  in  the  simulation  model  to  the  following  operations: 

1.  Time  lost  due  to  queueing  for  execution  at  arrival . 

2.  Message  transmission  time  (when  messages  are  sent  in  parallel, 
the  longest  time  interval  is  considered). 

3.  Queueing  time  in  the  Concurrency  Monitor  while  a  Read  or  write 
request  is  waiting  to  be  released  for  data  access. 

No  additional  overhead  or  operational  time  charges  are  made  in  the  for¬ 
mation  of  the  response  time  of  a  Transaction. 

The  performance  measurements  are  to  be  presented  as  a  series  of 
graphs  individually  representing  behaviour  of  Transactions  running  under 
PI,  P2  and  P3  respectively.  The  behaviour  of  each  protocol  type  is 
again  separated  over  a  series  of  Transaction  Interarrival  Time  graphs. 
The  arrival  rates  are  chosen  to  demonstrate  the  system  response  at  the 
limits  of  a  lightly  loaded  system,  a  near  saturated  system  and  a  set  of 
mid-range  arrival  rates.  The  variables  measured  are 

1.  Transaction  Response  Time  -  the  time  interval  beginning  with  the 
transaction  arrival  time  and  terminating  when  the  TM  sends  the 


write  message  to  the  DM.  It  is  assume j  that  3ll  transaction  read 
and  write. 

2.  The  number  of  Transaction  rejections.  (Rejections  are  retried  10 
times  and  are  then  retracted  from  the  system)  . 

3.  Queueing  time  in  the  Concurrency  Monitor  -  when  a  read  or  ’write 
request  is  waiting  to  be  released  for  data  access.  (When  parallel 
efforts  are  made,  the  longest  queueing  time  is  used). 

These  variables  are  plotted  as  a  function  of  the  delta-read-time  used  to 
form  the  Read  Timestamp  for  the  PI  and  P2  type  transactions.  Delta 
ranges  from  0.01  to  0.6  of  the  interval  between  this  timestamp  and  the 
timestamp  of  the  previous  transaction  of  that  class.  Each  graph  con¬ 
tains  a  family  of  curves  where  the  curve  parameter  is  the  NULLWRITE 
timeout  interval . 

Due  to  insufficient  time  to  complete  the  measurements  of  the  model  as 
described  in  this  report,  a  set  of  measurements  similar  to  those  des¬ 
cribed  above  but  relating  to  a  simplified  model  as  presented  here.  The 
simplification  of  the  measured  model  lies  is  the  assumptions  made  for 
the  data  base.  In  the  s.nple  data  base  there  are  no  fragments.  The 
data  base  a3  a  unit  is  replicated  at  each  DM.  Such  a  configured  dat3 
base  then  reduces  the  number  of  messages  sent.  In  addition  the  simple 
model  has  no  facilities  to  retry  transactions  that  were  rejected  during 
the  attempt  to  read.  Such  transactions  are  abandoned  in  the  simple 
model.  All  other  rules  for  the  implementation  of  the  transaction 
classes,  protocols,  and  the  concurrency  control  algorithm  are  the  S3me. 


Appendix  C  contains  two  sample  printouts  of  short  simulation  runs  of 
the  simplified  model.  The  first  set  of  output  data  represents  a  run 
made  for  the  collection  of  statistics  and  so  contains  no  additional 
tables.  The  second  run  was  made  to  illustrate  the  tracing  capability  of 
the  DISS  package,  the  Transaction  Completion  Table  and  the  DM  LOG  as 
prepared  by  the  SDD-1  algorithm  processes. 
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Chapter  VI 


PERFORMANCE  EVALUATION 

This  chapter  presents  the  performance  measurements  made  on  the  SDD-1 
model  representing  the  simplified  system  and  thus  the  simplified  data 
base . 

The  simulated  DB  is  a  collection  of  replicated  logical  fragments. 
Four  classes  of  transactions ,  denoted  as  class  //I  through  ?4,  are 
defined.  Class  definitions  and  the  corresponding  conflict  graph  are 
presented  in  Figure  2.  As  can  be  seen  from  the  conflict  graph,  classes 
1  and  4  have  no  conflicting  classes.  Class  2  must  parCor^n  p 2  against 
classes  i  and  3,  and  class  3  runs  P3  against  class  4. 

The  network  on  which  this  D3  is  implemented,  is  composed  of  two  cen¬ 
ters  with  three  nodes  in  each  one  of  them.  Figure  3  shows  the  network 
topology.  The  number  inside  each  node  is  the  node  ID  number,  and  the 
number  on  every  communiotion  line  is  the  delay,  in  milliseconds,  intro¬ 
duced  by  the  line  when  a  message  is  sent  through  it.  As  can  be  seen, 
the  communication  between  nodes  from  different  centers  is  twenty  times 
more  expensive  than  the  communication  within  the  center.  Nodes  1 
through  4  are  TMs  supervising  the  corresponding  classes.  Nodes  5  and  6 
are  DMs. 

The  effects  of  three  parameters  on  the  system  performance  is  des¬ 
cribed.  The  first  parameter,  called  Delta,  is  the  portion  of  the 
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Figure  3".  Network  Topology 
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'permitted  range'  subtracted  from  the  transaction  timestamps  to  create 
the  read  timestamps.  The  second  parameter  is  the  interarrival  time, 
IAT,  of  new  transactions  at  the  TMs .  And  the  third  is  the  timeout  inter¬ 
val,  TO,  invoked  before  requesting  or  sending  a  NULLWRITE.  The  system 
performance  is  characterized  by  the  average  Response  Time,  the  average 
time  spent  by  READ  requests  at  the  CMQs  (Read  CMQ  Time),  the  propor¬ 
tional  number  of  rejected  transactions,  and  the  average  number  of  mes¬ 
sages  sent  per  transaction.  The  simulation  results  are  summerized  in 
the  following  graphs.  All  time  units  are  in  milliseconds. 

Graphs  1  through  7  describes  the  average  response  time  as  a  function 
of  Delta,  for  different  classes  at  different  timeout  values,  TO,  for 
different  interarr ival  times,  TAT.  These  graphs  show  a  variation  of 
the  response  time  of  class  3  as  a  function  of  Delta.  Class  3  runs  P3 
therefore  it  is  not  directly  influenced  by  the  value  of  Delta.  The  var¬ 
iation  in  response  time  shows  the  dependency  between  classes  in  this 
system.  The  most  sensitive  class,  as  can  be  seen  from  these  graphs,  is 
class  7.  Therefore  the  remainder  of  this  chapter  will  concentrate  on 
this  class. 

Graphs  3,9  and  10  present  the  average  READ  CMQ  time  of  transactions 
from  clas3  2  as  a  function  of  Delta.  The  TO  and  IAT  are  similar  to 
those  in  graphs  5,5  and  7.  Comparing  the  response  time  with  the  read 
CMQ  time  shows  a  similar  behaviour  when  the  system  is  not  loaded  (large 
delta)  .  When  the  load  increases  and  the  response  time  climbes  very 
rapidly,  the  read  CMQ  time  tend3  to  stabilize  on  a  value  almost  indepen¬ 
dent  of  the  IAT.  This  value  indicates  3n  approximate  maximum  rate, 
under  a  given  TO,  at  which  the  DM  can  handle  data  access  requests. 
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A  trade  off  can  be  seen  by  comparing  the  response  tine  behaviour 
(graphs  5,6,7)  and  the  amount  of  transaction  rejections  (graphs 
11.12,13)  as  a  function  of  Delta,  Increasing  Delta,  improves  the  res¬ 
ponse  time  but  increases  the  number  of  rejections.  A  compromise  will  be 
found.  In  the  given  example,  a  Delta  of  0.2  -  0.3  seems  to  be  the  best 
choice . 

The  response  time,  the  read  GMQ  time  and  the  number  of  rejections, 
are  improved  as  TO  is  decreased.  On  the  other  hand,  the  number  of  mes¬ 
sages  sent  per  transaction,  increases  as  TO  gets  smaller  (graphs 
1*1,15,16).  In  a  system  where  the  communication  lines  are  used  not  only 
for  the  DDBMS,  and  the  lines  are  loaded,  increasing  the  number  of  mes¬ 
sages  is  not  desirable.  Graphs  14,15  and  16  indicates  that  for  this 
system,  the  number  of  messages  increases  very  sharply  for  TO  below  70 
miliseconds.  Taking  into  acount  all  these  effects,  the  measured  system 
is  expected  to  give  good  results  using  Delta=  0.2  -  0.3  ,  and  T0=  70  - 
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REJECTIONS  OF  TRANSACTIONS  FROM  CLASS  #2 
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Chapter  VII 


CONCLUSIONS  AND  RECOMMENDATIONS 

The  preliminary  performance  measurements  presented  in  this  report  are  a 
strong  indication  of  the  value,  flexibility  and  power  of  full  system 
simulation  using  a  modular  simulation  tool.  In  effect,  this  report  cov¬ 
ers  two  interrelated  areas  of  activity.  The  DISS  package  proved  to  be  a 
very  flexible  tool  and  proved  itself  by  the  relative  ease  with  which  the 
simplified  model  was  modified  to  the  full  fragmented  data  base  model. 
The  curtailment  of  the  program  did  not  permit  the  proper  completion  of 
the  intended  goals  of  the  development  effort  as  originally  intended.  It 
is  suggested  that  an  effort  be  made  to  prepare  the  necessary  documenta¬ 
tion  of  the  two  programming  sections.  The  DISS  package,  as  3  general¬ 
ized  simulation  aid,  is  intended  for  use  for  any  distributed  system 
simulation . 

The  simulation  program  of  the  SDD-1  algorithem,  p-epared  to  run  with 
the  DISS  package,  should  be  documented  3S  well  as  this  is  but  a  research 
tool  for  further  development  of  the  algorithm.  In  addition,  a  competing 
algorithm,  such  as  some  version  of  the  two  phase  locking  scheme,  should 
be  implemented  in  the  same  simulation  environment  so  that  an  objective 
comparison  of  the  efficiency  and  costs  of  the  different  schemes  may  be 
made . 
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Appendix  A 


THE  DISS  METHOD  OF  DISTRIBUTED  SYSTEM  SIMULATION 


Miron  Livny  and  Myron  Melman 
Department  of  Applied  Mathematics 
The  Weizmann  Institute  of  Science 
Rehovoth,  Israel 


A.1  ABSTRACT 

The  growing  activity  in  the  area  of  complex  distributed  systems  has 
introduced  the  need  for  simulation  aids  that  enhance  the  modeling  time 
of  these  systems.  A  simulation  modeling  tool  based  upon  the  Process 
concept  of  SIMSCRIPT  II. 5  and  addressing  itself  to  Fully  Distributed 
Processing  systems  is  presented  here.  The  package  is  based  upon  the 
principles  of  loosely  coupled  nodes  displaying  3  cooperative  autonomy  in 
their  internodal  relationship.  The  two  levels  of  modularity  used  offers 
flexibility  and  extensibility  of  the  models.  A  modeling  procedure  and 
example  are  presented. 
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A. 2  1.  INTRODUCTION 


O 

Fully  distributed  processing  systems  are  a  growing  phenomenon.  Their 
size,  complexity  and  cost  are  continuously  on  the  increase.  The  advisa¬ 
bility  to  construct  such  a  system  without  having  it  undergo  a  complete 
simulation  is  reduced  as  the  system  complexity  grows.  The  need  for 
simulation  aids  that  particularly  .address  the  needs  of  such  systems  is 
very  current.  This  paper  describes  a  software  package  that  was  devel¬ 
oped  for  the  express  needs  of  simulating  distributed  processing  systems. 
DISS,  Distributed  System  Simulator,  was  designed  to  support  and  comple¬ 
ment  the  modelers  efforts  to  simulate  multiple  node,  loosely  coupled 
networks  that  can  be  depicted  as  directed  graphs  of  arbitrary  topology. 

Modularity  and  extensibility  are  the  major  advantages  of  fully  dis¬ 
tributed  systems.  A  performance  study  of  such  a  system  will  undoubtedly 
include  an  anlysi3  of  the  impact  of  topological  changes  and  replacements 
of  components  on  the  performance  of  the  system.  Therefore  it  is  desired 
that  a  simulation  model  of  such  a  system  will  also  be  modular  and  exten¬ 
sible.  An  attempt  was  made  in  this  package  to  permit  the  modeler  full 
independence  in  the  choice  of  the  algorithmic  description  of  the  system, 
while  using  modular  structures  to  build  the  model.  DISS  was  written  in 
the  SIMSCRIPT  II. 5  programming  language  (1).  Previous  efforts  to  design 
simulation  models  of  distributed  systems  have  resulted  in  major  projects 
and  their  successful,  non-modular  organization  made  modifications  diffi¬ 
cult  and  their  use  for  near-like  models  impossible  (2), (3).  The  latter 
model  had  network  topology  flexibility  and  the  nodes  represented  pdp-11 


2  This  research  wa3  supported  by  the  United  States  Air  Force,  Air  Force 
Office  of  Scientific  Research  under  Grant  No.  AFOSR  81/0147. 
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systems  with  parametric  flexibility.  But  the  attempt  to  replace  the  CPU 
meant  to  redesign  the  entire  model.  Other  simulation  programs  and  pack¬ 
ages  have  been  designed  for  the  express  purpose  of  simulating  communica¬ 
tions  protocols  (4), (5). 

The  underlying  motivations  and  principles  of  the  type  of  system 
organization  with  which  the  package  is  intended  to  be  used  are  reviewed 
below,  and  the  content  and  services  supplied  by  the  package  routines  are 
discussed.  The  services  provide  a  cohesive  set  of  functions  that  are 
common  to  such  distributed  systems  displaying  decentralized  control  (6)  . 
This  package  capability  enables  the  modeler  to  concentrate  on  the  use  of 
a  highly  modular  method  of  algorithmic  descriptions  which  contain  the 
linkages  to  the  services  supplied  by  the  DISS  package.  The  package  con¬ 
siders  the  node  as  the  building  block  of  the  model.  The  specific  archi¬ 
tecture  suggested  for  the  node  is  based  upon  an  implementation  of  a  uni¬ 
que  'WAIT  UNTIL'  type  of  statement  used  when  alerting  nodal  members  of  a 
model.  The  organization  of  the  'WAIT  UNTIL'  strongly  suggests  a 
'PROCESS'  type  of  architecture  for  the  node  (7).  This  style  is  particu¬ 
larly  convenient  in  handling  loosely  coupled  nodes  that  can  accommodate 
multiple  resources  and  concurrent  timing  delays. 

Section  2  of  the  paper  describes  the  background  experience  that  moti¬ 
vated  the  preparation  of  the  package.  The  overall  structure  of  DISS  is 
presented  in  Section  3,  and  some  of  the  critical  design  features  of  a 
model  are  discussed  in  section  4.  The  suggested  architecture  of  the 
node  process  is  presented  in  section  5.  A  description  of  a  complete 
simulation  study  of  a  system  is  described  in  section  5  and  the  implemen- 
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tation  of  the  model  in?  procedure  on  a  sample  model  is  presented  in  sec¬ 
tion  7.  The  experience  of  the  authors  3nd  the  direction  for  future 
development  is  discussed  in  the  conclusions  of  section  9. 

A. 3  2.  MOTIVATION  FOR  PACKAGE  DESIGN 

The  organization  of  DISS  has  been  strongly  influenced,  if  not  guided,  by 

the  modeling  and  simulation  experience  of  the  authors  and  by  the  simul¬ 

taneous  formulation  by  Enslow  of  the  definitions  of  Distributed  Process¬ 
ing  Systems  (6).  The  simulation  studies  mentioned  above  were  of  distri¬ 
buted  processing  systems  ,  but  their  rigid,  non-modular  design  made  the 
models  useful  only  for  their  single  intended  experiment.  It  became 
clear  that  these  models  had  many  common  operating  characteristics,  yet, 
it  was  impossible  to  share  sections  of  one  model  with  sections  of 

another  model.  The  models  were  of  distributed  computers  and  of  computer 
networks.  As  such  they  are  depictable  as  directed  graphs.  These  dis¬ 
tributed  system  models,  without  a  centralized  controller,  allowed  com¬ 
plete  autonomy  to  each  node,  such  as  to  accept  or  reject  tasks,  and 

there  were  global  directories  so  that  the  task  in  the  node  did  not  see 
the  entire  system. 

The  explicit  features  of  such  distributed  systems  have  been  aptly 
detailed  by  Enslow  as  Fully  Distributed  Processing  Systems,  (FDPS),  dis¬ 
tinguishing  characteristics  (3);  the  multiplicity  of  system  resources, 
the  interconnection  of  the  nodes,  the  commonality  of  nodal  controls, 
transparency  of  the  system  to  the  task  and  the  autonomy  of  the  node.  Of 
these,  the  mo3t  distinguishing  attribute  was  singled  out  as  the  "cooper¬ 
ative  autonomy"  of  the  node.  It  was  realized  that  the  models  developed 
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were  functionally  abiding  by  these  characteristics  but  the  total  lack  of 


modularity  made  the  models  rigid  and  inflexible.  A  new  approach  was 
sought  that  would  encompass  the  desired  system  functioning  characteris¬ 
tics  while  at  the  same  time  permit  a  simplification  of  the  modeling 
procedure  and  allow  a  greater  degree  of  flexibility  in  the  implementa¬ 
tion.  It  is  the  belief  of  the  authors  that  the  DISS  package  presented 
in  this  paper  meats  these  aspirations. 

The  coupling  structure  between  nodes  is  critical  in  FDP  Systems  and 
is  reflected  in  the  design  of  all  nodal  elements.  Distributed  systems 
are  characterized  by  the  autonomy  of  their  elements.  The  elements  of 
the  system  are  interconnected  by  a  communications  network  through  which 
they  exchange  information.  The  means  by  which  the  communication  system 
transfers  data,  both  physically  and  logically,  should  not  violate  the 
autonomy  of  the  system  elements.  Therefore  a  fully  distributed  system 
has  to  be  both  physically  and  logically  loosely  coupled.  The  physical 
transfer  of  data,  the  physical  coupling,  has  to  be  performed  via  a 
shared  'mail  box'  that  is  not  an  integral  part  of  the  system  elements. 
In  a  distributed  computer  system  the  'mail  box'  should  be  an  on-line 
Input/Output  device  but  not  the  primary  memory  of  a  computer.  The 
autonomy  of  an  element  prohibits  any  external  access  to  its  internal 
storage  components.  It  is  the  duty  of  the  logic  associated  with  the 
transfer  mechanism,  the  logical  coupling,  to  determine  what  has  to  be 
done  with  the  data  stored  in  the  'mail  box'.  It  is  the  receiving  ele¬ 
ment  that  decides,  according  to  a  well-defined  two-party  cooperative 
protocol,  whether  to  accept  the  data  or  not.  The  development  of  DISS 
was  guided  by  the  idea  that  the  'loose  physical  coupling'  of  the  distri- 
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buted  system  should  be  reflected  in  the  structure  of  the  model  that  is 
supported  by  DISS,  and  that  the  modeler  should  be  provided  with  means 
that  will  enable  him  to  model  loosely  coupled  logic. 

The  basic  and  underlying  assumptions  in  the  development  of  DISS  is 
that  all  such  FDP  Systems  can  be  mapped  into  directed  graphs.  The  mode¬ 
ler  is  left  with  the  task  of  formulating  his  distributed  system  into  a 
set  of  unique  discrete  nodes.  At  the  outset  of  the  experiment,  when 
establishing  the  network  in  preparation  f*'r  simulation  the  nodes  are 
placed  in  their  relative  positions  in  the  graph  and  are  interconnected 
by  the  arcs.  The  mechanism  used  for  transfering  information  along  the 
arcs  enable  the  node  to  maintain  its  physical  and  logical  autonomy.  The 
mapping  conforms  to  the  topology  selected  by  the  modeler. 

A. 4  3.  THE  STRUCTURE  OF  DISS 

The  package  has  been  organized  as  a  set  of  subroutines  that  are  called 
by  the  model  at  various  stages  of  the  simulation  experiment,  to  perform 
those  operations  that  are  common  to  all  FDP  Systems.  The  DISS  routines 
are  general  in  nature  but  they  clearly  address  themselves  to  systems 
being  modeled  that  display  the  above  mentioned  characteristics.  The 
routines  are  grouped  into  activity  areas  that  3re  shown  in  Fig.  1.  Each 
node  of  the  system  model  is  capable  of  supporting  any  number  of  pri¬ 
vately  managed  or  3hared  resources  and  is  connected  by  means  of  arcs  to 
its  neighbor  nodes.  These  arcs  carry  the  internodal  communications  for 
the  systen.  The  node  of  the  network  Is  designed  to  have  its  own  control 
rules,  and  is  determined  by  the  system  requirements .  Each  node  of  the 
system  may  be  unique  or  all  nodes  may  be  identical.  However,  there  may 
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be  certain  overall  system  control  rules  that  are  common  to  all  nodes. 


System  transparency  and  element  autonomy  are  the  powerful  levers  of  con¬ 
trol  that  the  model  imparts  to  the  node.  The  degree  of  this  control  and 
the  style  of  its  implementation  is  left  to  the  modeler.  DISS  gives  the 
modeler  the  impression  that  he  is  using  a  language  that  is  in  both  the 
functions  and  data  structures  it  provides  one  level  higher  than  SUB¬ 
SCRIPT  II. 5.  All  these  structures  and  functions,  however,  are  obtained 
by  the  use  of  SUBSCRIPT  II. 5  statements. 


SYSTEM  ESTABLISHMENT 
STATE  VARIABLES 
EXPERIMENT  CONTROL 
LOCAL  STRUCTURE  ALLOCATION 
TIMING 

NODE  COUPLING 
REPORT  GENERATION 
DEBUGGING  AIDS 
STATISTICAL  ANALYSIS 


Figure  1  Activity  Areas  of  DISS 
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As  3  result  of  familiarization  with  DISS,  the  modeler  should  have  an 
understanding  of  the  characteristics  of  FDPS,  those  services  provided  by 
the  package  and  therefore  a  picture  of  how  and  when  these  services  are 
called  for  from  within  the  model.  This  then  leaves  the  modeler  to  con¬ 
centrate  on  the  needs  of  the  particular  system  to  be  modeled  and  to 
design  the  unique  instances  of  network  nodes.  Therefore  the  amount  of 
code  that  the  modeler  need  prepare  and  debug  is  reduced. 

A. 5  4.  MODAL  COUPLING 

DISS  regards  the  node  of  the  model  as  a  physical  and  logical  autonomous 
element.  In  order  to  enable  the  exchange  of  data  between  two  nodes  DISS 
provides  means  for  the  physical  coupling  of  the  nodes  that  can  be  cont¬ 
rolled  by  the  logic  of  the  nodes,  the  protocol.  In  the  directed-graph 
representation  of  the  model  the  arcs  of  the  graph  represent  the  physical 
coupling  between  two  nodes.  A  directed  arc  that  goes  from  one  node,  the 
source,  to  another,  the  target,  represents  the  ability  of  the  source  to 
transfer  information  to  the  target.  In  a  discrete  event  model  the 
transfer  of  data  from  one  node  to  another  is  associated  with  a  change  in 

the  st3te  of  the  source.  The  information  transferred  describes  a  change 

in  state  like  'start',  'end  of  message  transfer',  'task  arrival', 
'buffer  full’,  'server  not  busy'  etc. 

DISS  implements  each  arc  as  a  group  of  variables,  an  entity,  that  can 
be  considered  as  a  'mail  box'  into  which  the  source  writes  and  from 
which  the  target  reads.  The  arc  consists  of  a  standard  set  of  variables 

and  the  modeler  can  increase  the  number  of  variables  according  to  the 

requirements  of  his  model.  DISS  considers  two  types  of  information 
transfers,  active  transfer  and  passive  transfer. 
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A. 5.1  Active  Transfer 


When  an  active  transfer  of  information  takes  place  the  data  is  stored  in 
the  'mail  box'  and  an  attempt  is  made  to  ALERT  the  target  node.  The 
change  in  the  st3te  of  the  source  is  considered  an  External  Event  for 
the  target.  The  target  might  be  waiting  for  this  event  and  therefore 
has  to  be  alerted  as  the  event  takes  place.  The  data  stored  in  the 
'mail  box'  describes  the  change  in  the  state  of  the  source.  Each  node  is 
provided  with  means  by  which  it  can  dynamically  enable  and  disable 
alerts  of  selected  External  Events.  If  the  event  that  caused  the  active 
transfer  was  masked  by  the  target  node  the  alert  will  be  pended  so  that 
when  the  mask  is  removed  the  target  node  will  be  alerted.  The  masking 
mechanism  thu3  ensures  the  logical  autonomy  of  the  nodes.  One  node  can 
not  force  another  node  to  do  anything  unless  the  node  wants  to  cooper¬ 
ate.  The  active  transfer  of  data  is  carried  out  by  the  ALERT  routine 
that  receives  the  description  of  the  event  via  parameters.  The  data 
structures  associated  with  the  transfer  are  established  by  the  DISS 
routines  at  network  establishment. 

A. 5. 2  Passive  Transfer 

A  node  may  be  interested  in  making  certain  state  variables  visible  to 
another  node  while  changes  in  these  variables  will  not  cause  an  External 
Event.  In  such  cases  a  change  in  one  of  the  state  variables  that  des¬ 
cribe  these  aspects  will  cause  a  passive  transfer  of  data.  The  trans¬ 
ferred  dat3  is  placed  in  the  'mail  box'  by  the  source  node.  The  varia¬ 
bles  used  by  the  passive  transfer  3re  called  the  INTER  NODAL  STATE 
VARIABLES  of  the  arc.  Each  incoming  or  outgoing  arc  is  considered  as  a 
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port  of  the  node.  The  data  is  sent  and  received  according  to  port  .num¬ 


bers.  Each  input  port  can  be  assigned  a  priority  so  that  the  data 
transfer  activity  can  utilize  priority  schemes. 

The  nodal  coupling  of  DISS  does  not  rely  on  any  structural  dependency 
between  the  source  and  target  nodes.  The  source  node  can  transfer  data 
without  knowing  anything  about  the  structure  of  the  target.  Thus  any  two 
nodes  that  follow  the  same  protocol  can  exchange  information  along  an 
arc . 


A. 6  5.  THE  PROCESS 

DISS  considers  a  SIMSCRIPT  PROCESS  as  the  unit  of  nodal  activity  for  the 
model.  There  may  be  a  single  Process  type  for  all  nodes  or  there  may  be 
a  unique  Process  type  for  every  node.  In  all  combinations  of  Processes, 
they  must  all  contain  common  structural  and  interfacing  statements  that 
link  them  to  DISS.  To  control  the  experiment  the  modeler  need  prepare  a 
special  Process,  called  Executive  Manager,  (EM),  that  manages  the 
sequencing  of  the  complete  experiment.  Fig.  ?  is  a  block  diagram  of  a 
typical  Process  organized  to  operate  with  DISS.  The  structure  is  capa¬ 
ble  of  maintaining  the  distinguishing  characteristics  of  a  Fully  Distri¬ 
buted  Processing  System.  The  focal  point  of  the  organization  is  the 
loop  structure  that  is  controlled  by  the  "WATT  FOR  ALERT"  function. 
This  represents  a  generalized  "WAIT  UVTIL”  implementation  and  is  the  key 
to  the  Process  operation  (9). 

The  "WAIT  FOR  ALERT"  function  of  DISS  enables  the  Process  to  enter  a 
passive  state  until  one  of  a  number  of  events  will  take  place.  The 


-  60  - 


"WAIT  FOR  ALERT"  mechanism  is  equivalent  to  a  generalized  "WAIT  UNTIL" 
with  a  condition  that  is  a  logical  concatenation  of  the  External  Events 
of  the  node  and  of  the  internally  scheduled  nodal  delays.  The  mechanism 
transfers  the  imperative  scheduling  of  SI'dSCRIPT  into  an  interrogative 
scheduling  mechanism.  The  interrogative  scheduling  of  DISS  is  the  foun¬ 
dation  of  the  autonomy  of  the  node. 


Figure  ?  Typical  Process  Structure 


The  Process  is  activated  by  DIS5  and  is  permitted  to  execute  its  ini¬ 
tialization  period.  During  this  operation  the  Process  uses  DISS  to 
establish  the  local  structures  that  will  be  used  during  the  experiment 
and  to  obtain  from  the  nodeler  any  personalizing  characteristics 
required  by  the  node.  Simulation  may  not  begin  until  all  Processes  have 
been  initialized  so  it  is  convenient  to  have  the  Process  suspend  at  the 
end  of  this  interval.  The  "WATT  FOR  ALERT"  function  serves  this  purpose 
at  this  time. 

As  mentioned  in  the  last  section,  the  coupling  mechanism  has  the 
capability  of  alerting  a  Process  when  implementing  an  External  Event. 
The  Process,  as  shown,  is  structured  to  receive  three  types  of  alerts; 
External,  Internal  and  termination.  The  External  alerts  are  invoked  by 
neighbor  nodes  that  communicate  over  the  interconnecting  arcs  and  repre¬ 
sent  the  termination  of  massage  transmission  to  this  node.  Internal 
alerts  are  terminations  of  time  delays  that  have  been  scheduled  by  this 
Process  while  the  termination  alert  is  scheduled  for  all  Processes  by 
the  Eld  at  the  instance  of  the  end  of  simulation  time. 

At  the  entry  to  the  "Wait  For  Alert'  state  from  either  the  initiali¬ 
zation  path  or  from  the  iterative  loop  p3th,  the  Process  logic  invokes  a 
check  for  the  presence  of  a  pending  alert.  DISS  provides  the  means  for 
automatically  testing  for  the  presence  of  such  an  alert,  in  which  case 
the  Process  continues  to  execute,  or  for  the  absence  of  such  an  alert, 
in  which  ca3e  the  Process  suspends.  Once  suspended,  the  Process  waits 
for  the  next  event  to  occur.  In  case  the  Process  has  been  suspended, 
DISS  provides  the  automatic  means  by  which  an  event  alert  may  resume  the 
Process . 
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When  designing  the  Process  the  modeler  has  several  options  for  the 
processing  of  event  alerts.  The  modeler  can  use  either  a  single  mask 
flag  for  global  Process  event  enabling  or  he  nay  select  the  use  of  a 
more  sophisticated  mask  vector  that  would  relate  each  mask  element  to  a 
particular  event  handled  by  the  Process.  If  the  global  mask  is 
selected,  DISS  provides  all  support  required.  If  the  latter  method  is 
chosen  then  the  modeler  must  provide  a  routine,  called  EV. SELECT,  in 
which  the  coded  event  alert  identification  is  matched  against  the 
related  enabling  mask  vector  element.  The  sequence  of  selecting  the 
pending  active  event  alerts  for  acceptance  is  determined  by  a  scheduling 
or  priority  algorithm  suitable  to  the  needs  of  the  Process.  If  this 
invoked  procedure  occurred  when  the  Process  was  suspended  and  an  active 
alert  is  accepted,  the  Process  is  resumed. 

From- Fig.  2  it  is  seen  that  once  resumed  the  Process  selects  any  one 
of  a  number  of  execution  paths  that  algorithmically  describe  the  needs 
of  the  node  as  a  reaction  to  the  particular  motivating  Internal  or 
External  Event.  The  functions  are  modular  within  the  Process  and  are 
simple  to  remove  or  insert.  The  internal  design  of  the  function  is  also 
modularly  structured  and  is  simple  to  design  and  manipulate.  In  gen¬ 
eral,  the  functions  are  used  to  generate  additional  activities;  monitor 
system,  node  and  function  status;  and  make  the  required  measurements 
pertinent  to  the  motivating  event.  The  modular  function  is  then  clearly 
linked  to  the  event  that  caused  the  iteration  through  the  Process.  In 
keeping  with  the  SIMSCRIPT  language,  each  Process  and  function  may  have 
its  own  resources.  The  loop  structure  and  the  multiple  parallel  path 
concept  enable  the  modeler  to  introduce  simultaneous,  concurrent  time 


delays  within  the  sane  Process.  This  can  represent  concurrent  message 
transmission  over  different  arcs,  or  concurrent  utilization  of  multiple 
resources  within  the  Process. 

Report  generation  at  the  end  of  the  simulation  run,  per  Process,  is 
initiated  by  a  termination  event  scheduled  by  the  Executive  manager. 
The  modeler  is  free  to  organize  and  print  the  performance  data  as  best 
suites  the  model.  The  termination  function  should  also  handle  the 
release  and  resetting  of  those  SIMSCRIPT  structures  that  would  be 
required  to  permit  the  outer  looping  of  additional  system  runs.  The 
Process  may  then  be  self  destroyed. 

A. 7  6.  SIMULATION  STUDY  WITH  PISS 

The  interdependent  modeling  concepts  to  represent  FDP  Systems  with  the 
use  of  the  DISS  package  have  been  described  in  the  preceding  sections. 
The  various  stages  of  formulating  a  simulation  study  of  a  specified  sys¬ 
tem  can  be  visualized  by  a  sequence  of  clearly  defined  operations.  Fig. 
3  shows  the  conceptual,  planning  and  implementation  phases  used  to 
achieve  such  a  study. 

The  system  under  consideration  either  exists  or  is  somehow  specified. 
In  either  case  a  detailed  analysis  of  the  system  is  to  be  made  so  that 
there  is  a  clear  understanding  of  the  operations  executed  by  the  system, 
of  the  characteristics  of  the  system  resources,  and  of  the  nature  o'  the 
workload.  The  scope  of  the  experimental  frame  (10)  should  be  clear  from 
the  outset  of  the  study,  why  simulate,  what  performance  information  is 
expected  from  the  study. 
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Figure  3  Phases  of  Simulation  Study 


Once  analyzed,  the  system  is  ready  to  be  modeled.  It  is  at  this 
point  that  the  choice  of  simulation  methodology  is  to  be  made.  For  the 
instance  of  this  paper,  the  modeler  has  SIMSCRIPT  II. 5  and  is  familiar 
with  DISS.  The  modeler  should  have  a  clear  picture  as  to  the  alterna¬ 
tives  available  for  selecting  the  modeling  units  to  represent  the  build¬ 
ing  block  elements  of  the  real  system.  The  leading  decision  to  be  made 
is  how  many  unique  Process  types  are  required  to  model  the  system. 
There  may  be  several  answers,  but  one  of  them  will  give  the  optimal  ove¬ 
rall  simulating  conditions.  The  number  of  unique  node  types  can  have  a 
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direct  effect  upon  the  topology  selected,  so  that  the  resulting  topology 
of  the  model  may  bear  no  resemblenoe  to  the  distributed  network  used  in 
the  physical  system  (11).  Upon  determining  the  number  of  unique  nodes, 
the  modeler  is  left  with  the  task  of  using  the  system  analysis  informa¬ 
tion  to  map  the  system  algorithms  into  modular  functions  to  be  designed 
into  the  node.  These  are  to  be  grouped  into  externally  and  internally 
invoked  events.  The  internodal  state  variables  for  each  arc  may  then  be 
defined . 

The  implementation  phase  begins  with  the  coding  of  the  functions  and 
the  grouping  of  these  modular  sections  into  the  node  Process  shown  in 
Fig.  2.  During  this  stage,  the  modeler  places  the  various  interfacing 
calls  to  invoke  DTSS  services.  When  the  node  Processes  are  complete  the 
modeler  will  organize  the  Executive  Manager  Process.  By  this  time  the 
modeler  should  have  a  clear  picture  of  the  sequencing  of  the  simulation 
experiment.  These  global  controls  may  effect  the  nodal  functions  in 
which  case  the  modifications  are  made  to  the  nodes.  Note  that  in  this 
phase  of  implementation  both  function  and  node  Process  are  modular.  It 
is  this  feature  that  ensures  the  extensibility  of  the  model. 

The  model,  written  in  SIMSCRIPT  II. 5,  is  now  ready  to  be  run.  It 
remains  for  the  modeler  to  prepare  the  topology  of  the  model  in  the 
required  format  and  to  organize  the  personalizing  parameters  for  each  of 
the  node  Processes,  those  global  parameters  oriented  to  the  modeled  sys¬ 
tem  and  those  parameters  required  by  DISS.  When  prepared,  the  program 
is  ready  to  be  run.  The  modeler  will  manage  the  experiment  as  best 
3uits  the  study. 
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As  can  be  seen  from  Fig.  3.  the  preparations  of  the  parameters  infers 
a  simulation  run.  Depending  upon  the  demands  of  the  experimental  frame 
it  may  be  possible  to  execute  statistical  analysis  after  a  single  run  or 
it  may  be  necessary  to  make  parametric  changes  and  repeat  the  run  sev¬ 
eral  times  before  executing  the  statistical  analysis.  After  the  analy¬ 
sis  it  is  usually  desirable  to  compare  the  results  with  additional  topo¬ 
logical  configurations .  In  that  case  the  loop  into  the  topology  is 
used,  the  change  in  topology  is  made  and  the  inner  loop  is  repeated. 
The  topology  loop  may  be  repeated  according  to  the  needs  of  the  experi¬ 
mental  frame. 

It  may  be  required  to  change  the  experimental  frame  which  will  cause 
a  change  to  the  model  structure.  In  that  case  the  loop  is  extended  to 
the  next  level  and  the  modular  implementation  features  of  the  model  will 
permit  a  fast  program  modification.  The  model  may  then  by  reactivated 
as  though  from  the  start.  The  outer  loop  calls  for  a  change  to  the 
model  concept  with  means  a  basic  change  in  the  system  analysis. 

A. 8  7.  EXAMPLE 

Assume  that  a  simulation  study  of  the  following  system  has  to  be  per¬ 
formed  and  that  the  model  of  the  system  will  be  implemented  using  DISS. 
The  modeling  phase  of  the  study  is  presented  step  by  step  below.  The 
system  to  be  modeled  is  a  distributed  processing  system  that  consists  of 
a  number  of  HOSTS  that  are  interconnected  by  a  message  switching  store- 
and-forward  communication  system  as  shown  in  Fig.  M.  The  network  is 
made  up  of  communication  processors,  CP,  that  are  connected  by  full-du¬ 
plex  communication  lines.  Each  CP  has  a  finite  buffer  space  into  which 


the  messages  are  stored.  Therefore  the  communication  protocol  performs 


a  ’space  reservation'  step  before  a  message  is  transmitted.  Each  HOST 
receives  an  independent  stream  of  tasks.  Every  task  is  assigned  an  exe¬ 
cution  site  at  which  it  will  be  served.  This  assignment  is  performed  by 
the  resource  allocation  algorithm  of  the  distributed  system. 


Figure  4  The  Distributed  System 


Given  the  definition  of  the  system  the  modeling  phase  is  executed  by 
the  ensuing  3teps: 
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A. 8.1  Node  Definition 


The  elements  of  the  above  system  may  be  grouped  into  nodes  In  a  number 
of  ways  three  of  which  will  be  listed  here: 

1.  Each  element  of  the  system  defines  a  node.  The  model  will 
include  two  types  of  nodes. 

2.  The  HOST  and  the  CP  are  grouped  into  one  node  so  that  the  model 
has  only  one  type  of  node.  An  input  parameter  will  determine 
whether  the  node  is  a  HOST,  a  CP  or  both. 

3.  A  HOST  defines  one  type  of  node  whereas  3ll  the  communication 
processors  of  the  network  are  grouped  into  a  second  node  type. 
This  second  node  will  represent  the  entire  network.  In  this  case 
the  topology  of  the  network  will  be  represented  internaly  by  this 
node. 

The  selection  of  a  mapping  scheme  depends  strongly  on  the  experimentel 
frame  of  the  study.  Each  of  the  above  schemes  can  be  considered  as  the 
best  under  the  requirements  of  a  different  study.  One  scheme  may  be 
more  modular  whereas  another  one  may  h3ve  a  more  efficient  implementa¬ 
tion.  A  detailed  analysis  of  the  above  schemes  is  beyond  the  scope  of 
this  paper.  For  the  purpose  of  this  example  it  will  be  assumed  that  the 
first  scheme  h33  been  selected. 
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A. 8.2  Internodal  State  Variables 

After  the  elements  are  grouped  into  nodes  the  External  Events  of  each 
node  and  the  internodal  state  variables  have  to  be  defined.  Each  arc  of 
the  model  will  include  the  following  state  variables: 

1.  BUFFER. FULL  indicates  the  state  of  the  message  buffer  of  a  CP. 

2.  WATT  will  be  set  whenever  the  node  wants  to  transfer  a  message 
along  the  arc  and  the  buffer  of  the  target  node  i3  full. 

These  two  variables  are  used  for  the  passive  transfer  of  state  informa¬ 
tion  between  the  nodes. 

A. 8. 3  External  Events 

The  External  Events  of  the  CP  nodes  will  be  the  following: 

1.  START  OF  MESSAGE  ARRIVAL.  The  source  node  has  started  the  tran¬ 
smission  of  a  message. 

2.  EHD  OF  MESSAGE  ARRIVAL.  Th  3ource  node  has  terminated  the 
transfer  of  a  message. 

3.  BUFFER  AVAILABLE.  This  event  takes  place  whenever  the  state  of 
the  buffer  changes  from  full  to  available  and  the  target  node  is 
in  a  wait  state. 

The  set  of  External  Events  of  the  HOST  node  will  include  only  two  out  of 
the  above  three  events.  The  START  OF  MESSAGE  ARRIVAL  Event  is  not  con¬ 
sidered  as  an  External  Event  by  the  host.  The  reservation  step  per- 
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formed  by  the  CP  as  a  result  of  this  event  are  not  part  of  the  host 
functions . 

Note  that  this  structure  of  the  model  gives  the  CP  full  autonomy  in 
allocating  available  buffer  space.  By  means  of  the  BUFFER. FULL  variable 
and  the  BUFFER  AVAILABLE  event  it  can  select  which  waiting  CP  will  be 
given  a  buffer  space  that  has  become  available. 

A. 8. 4  Internal  Events 

Before  each  node  can  be  implemented  as  3  process  the  Internal  Events  of 
each  node  have  to  be  defined.  The  HOST  node  includes  the  following 
Internal  Events: 

1.  END  OF  MESSAGE  TRANSMISSION.  This  event  represents  the  delay 
associated  with  the  transfer  of  a  message. 

2.  END  OF  TASK  EXECUTION.  The  end  of  the  execution  period  of  a  task 
is  represented  by  this  event. 

3.  TASK  ARRIVAL.  The  arrival  procedure  of  the  tasks  is  modeled  by 
this  event.  The  arrival  of  one  task  causes  the  scheduling  of  the 
next  arrival. 

The  CP  has  only  the  END  OF  MESSAGE  TRANSMISSION  event.  The  above  set  of 
Internal  Events  enable  the  HOST  to  control  a  number  of  service-resources 
simultaneously.  The  CP  can  simultaneously  transfer  a  number  of  messages 
along  different  arcs. 
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In  this  example  the  outline  of  a  model  of  the  above  distributed  sys¬ 
tem  was  represented.  it  is  clear  that  the  model  defined  above  is  not 
the  only  way  suoh  a  system  can  be  modeled  and  implemented  by  DIS5. 

A. 9  8.  CONCLUSIONS 

In  this  paper,  the  authors  have  shown  that  by  using  an  integrated  design 
concept  the  modeling  effort  of  Fully  Distributed  Processing  systems  may 
be  minimized.  The  loop  structure  of  the  node,  the  "WAIT  FOR  ALERT" 
implementation,  the  loose  coupling  of  the  nodes  and  the  timing  mechanism 
of  DISS  form  that  integrated  concept. 

The  DISS  package  has  been  in  operation  for  some  time  now.  The  exper¬ 
ience  of  the  authors  indicates  that  its  use  h3S  considerably  enhanced 
the  challenge  of  modeling  such  systems.  Two  major  simulation  studies 
were  undertaken  with  the  use  of  DISS:  The  first  was  a  study  of  the  ETH¬ 
ERNET.  Besides  preparing  an  Executive  Manager,  the  ETHERNET  system  was 
conveniently  modeled  into  two  Processes,  the  'Physical  Layer'  and  the 
'Data  Link  Layer'  .  The  latter  Process  can  then  be  used  for  as  many 
nodes  as  desired.  The  topology  ended  up  as  a  star  network  with  the 
'Physical  Layer'  as  the  focal  point.  The  complete  basic  model  was  then 
replaced  by  a  lumped  model  (10)  of  the  system  to  compare  the  system  per¬ 
formance  under  these  two  modeling  conditions.  This  experiment  was  the 
basis  for  testing  three  load  balancing  algorithms  (11). 

The  second  system  is  a  model  of  the  SDD-1  Concurrency  Control  Algor¬ 
ithm  representing  a  fully  distributed  multiple  copy  data  base  system. 
Again,  besides  the  EM  only  two  Processes,  the  'Transaction  Manager'  and 
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the  'Data  Manager'  were  written.  These  models  have  bean  run  for  differ¬ 


ent  numbers  of  nodes  3nd  in  several  network  topologies. 

Continued  work  with  DISS  will  broaden  the  library  of  routines  availa¬ 
ble  to  the  modeler  and  will  include  sets  of  modular  nodes  and  modular 
functions.  Additional  simulation  aids  in  the  field  of  report  generation 
and  statistical  analysis  will  enrich  the  package  and  offer  the  modeler  a 
wider  range  of  options. 


-  73  - 


j 


REFERENCES 


RUSSELL,  E.D.  Editor  SIMSCRIPT  II. 5  Programming  Language.  C.A.C.I.  Inc. 
1973 

BARAK,  A.B.  and  MELMAN,  M.  "Minimal  Configuration  of  a  Flexible 

Expandable  Distributed  Processing  System."  Information  Technology 
(Proa.  Jerusalem  Conference  on  Information  Technology,  3rd,  Moneta, 

J.  Editor,  North-Holland  Publishing  Co.  p  27-31.  1973 

FENIG,  B.  and  MELMAN,  M.  "Simulating  a  Distributed  Computer  System 
Network  With  a  Generic  Modeling  Tool."  Proc .  IMAC  European 
Simulation  Meeting  University  of  Patras,  Patras,  Greece,  Oct.  2-4, 
1979,  Tzafestas,  S.Y.  Editor,  North-Holland  Publishing  Co.  1930 

SCHNEIDER,  G.M.  "A  Modeling  Package  for  Simulation  of  Computer 
Networks."  Simulation  December  1973,  p  182-192.  1973 

SHOEMAKER,  S.  Editor  Computer  Networks  and  Simulation.  North-Holland 
Publishing  Co.  1979 

ENSLOW,  P.H.  "’What  is  3  'Distributed'  Data  Processing  System?" 

Computer  January  1973,  p  13-21.  1978 

RUSSELL,  E.D.,  Simulating  with  Processes  and  Resources.  C.A.C.I.  Inc. 
1975  '  “  . “ 

ENSLO'W,  P.H.  and  SAPONAS,  T.G.  "Distributed  and  Decentralized  Control 
in  Fully  Distributed  Processing  Systems."  Final  Technical  Report 
GIT-ICS-31 /02 ,  Georgia  Institute  of  Technology,  School  of  Information 
and  Computer  Science,  Atlanta,  Georgia  39332,  1931 

FRANTA,  W.,  A.  Process  V iew  of  Simulation  North-Holland,  New  York,  1977 

ZEIGLER,  B.P.  Theory  of  Modelling  and  Simulation.  John  Wiley  A  Sons, 
New  York  1976 

LIVNY,  M.  and  MELMAN,  M.  "Load  Balancing  in  Homogeneous  Broadcast 
Distributed  Systems."  Proc.  ACM  Computer  Network  Performance 
Symposium  April  13-14,  College  Park,  Maryland,  1932 


Appendix  B 


SCAM  -  BLOCK  DIAGRAM 


-  75 


Appendix  C 


SIMULATION  RESULTS 


76 


R52BT001 


F  ILF 


2 


HISS 


PUN  NO.  1  :  SIMPLE  MCOfcL  ,  TRACE  ,  LEGS 


!  NPUT  EOF  THE  Ri)N 


nneAL  p ar  a  r  tT  ers 


T  I  Mfc  UN' ITS 

NUMRfcR  C E  (LAPSES  IN  TEE  SYSTER 
RAX  NijR  CF  FRAGMENTS  PER  SET 
A  Vl  E A  Gr  LfcNGTE  CE  a  gcntrcl  message 
EATCE  SIZE 
CCNFICFNCE  LEVEL 


m  ILL  I  SECCNDS 
A 


c 

C.30  (UNITS  UE 
2  E 

C.  90 


T  IRE  > 


FLAGS 

TRACE  FLAG  IE 

TRACE  DRIVEN  FLAG  0 

ICG  FLAG  1 

PROTOCOL  H MR" r  S 

r  (  A  S  S  i  2  J  4 

RPCTCC"IL  12  3  1 


F  CNEL IC  T  CLASS  MATRIX 


1 

2 

J 

4 

1 

j 

1 

C 

n 

0 

C 

2 

1 

0 

1 

0 

3 

0 

0 

0 

1 

4 

G 

a 

0 

0 

NCOt 

OAR  AC  T  ER  IZ  AT  1CN 

TRAN 

s 

A  V 

s 

DATA 

S 

READ  1 

PECS 

INT 

E 

PPCG. 

F 

ACCES 

E 

T  IRE 

DL  1 

TIME 

NOOE  .  If 

TYPE 

CLASS 

ARR 

E 

length 

F 

TIRE 

E 

CUT 

PL  R 

ST  ARPl 

1  EXPO  > 

D 

1 E  XPC  » 

6 

(EXPC  » 

D 

(FIX* 

FLG 

DELTA 

L 

TR 

l 

1CC.0 

4 

2.0 

5 

100. 0 

1 

.2000 

2 

TV 

2 

T  CO*  0 

6 

2.0 

7 

•  00  .0 

1 

.  xooa 

3 

T  R 

3 

100 .0 

e 

2.0 

9 

ICC.C 

1 

4 

TR 

4 

ICO.  0 

to 

O 

• 

f\: 

11 

100  .0 

1 

.2000 

5 

LR 

3.0 

2 

ICC.C 

1 

t 

DM 

3.0 

3 

I0C.0 

I 


15.54.4* 


ACE  t  LCGS 


IMe  » 


READ 


T  IRE 
CUT 

IF  I  X  > 

DU 

PCR 

FIG 

TIME 

STAMP 

DELTA 

100. 0 

1 

.2000 

100.0 

I 

./000 

icc.c 

100  .0 

l 

.2000 

N  5  2BT0O  T  FILE 


HISS 


SYSTEM  PERFORMANCE  RESULTS 


SINULATICN  TIME  =  350.0  UNITS 

T M  NCCE  STATISTICS 


NCr< 

in 

NUM 

TR  AN 
CCMP 

TR  ANS 

TM  c. 

TIME 

AVG  « 

In  A  IT  . 
TRANS 

t  CF 

PE  JEC 
IPANS 

TM 

L  T  I  L  . 

AVG 

RESPC 

T  IMF 

RESPC  e« 

TIME  aw 

STD  Sfl 

i 

A 

2.616 

•  0  3C 

C. 

•  364 

34  .444 

33.174 

? 

3 

23.463 

.201 

0. 

.7  14 

106. 62C 

ie.^i  j 

3 

1 

.CCC 

C. 

0. 

.362 

116.154 

o.  j 

3 

22.426 

.192 

0  . 

.3  17 

5  S • 4C4 

36.3EI 

DM  NCOE  STATISTICS 

R  E  AC  V*  P  I  T  E 

N'Gl;  CMQ  CVG 

TC  TINE  TIME 

5  -43.366  11.353 

6  42.C15  .CCC 


C-LCE  AL  STATISTICS 


N  U  M  f3  fc  P  CF  TRANSACT  ICNS  A  P  R  I V  E  C  IN  SYSTEM 
NIIMPEP  OF  TRANSACTIONS  PROCESSED  (  A  F  1 E  R  WRITES) 

NUMBER  CF  TRANS ACTICNS  REJECTED 

NUMBER  CF  MESSAGES  SENT  PER  TRANSACTION  ,  AVC  UNC.  Nhl  9< 

AVG.  SYSTEM  TIME  PER  TRANSACTION  93, 

SVG.  TRANSM  I S  S  ICN  TIME  PER  TP  ANSACT  1CN  <NCT  INC.  NK  I  17l 

AVG.  RFSFNSE  TIME  PER  TRAN  SAC  T ICN  68, 


C  I  s  s 


15.54.5C  C 2-  5-82  FACE-  3 


1 


A  VG 

RESPC 

BATCH 

RESPC 

T  IRE 

AVG 

TIRE 

STC 

STC 

34  .444 

38.174 

106 .E2C 

18. 

118.154 

0. 

55.404 

J6  .  Jtl 

R  fc  L  /» T 
FREC  1 

IN  *  CCPR 


NU* 

CF 

BATCHES 


I 


12 

11 

C 

9.2500 

93.7740  CM  T  S 
17.5439  IMTS 
68.6003  IMTS 


THE  RUN  NEEEEC  1.85  CPC  SECONDS 


i 


N52BTC01 

6111:  - 

3 

C  I  s  s 

t  ipe.v  ncde 

TR.NC 

1 

=  =  = 

EVENT,  NA*E  =  NUP1, 

Til 

SSSl 

13.6 

2 

1 

1AM,  CLAS  = 

2 

1 J.  6 

1 

1SRD  ,DE ST  = 

5  1104 

14.6 

5 

1 

CARCtCLAS*  2  1102 

14.6 

5 

l 

DPPR.PPIC*  1102 

1 1C2 

14.6 

5 

1 

DNFR  tPSlF  = 

3 

1102 

14.6 

£ 

1 

CP1C,CLAS= 

45.4 

2 

2 

TANT,CLAS= 

2 

76.2 

4 

3 

IAMtCUSr 

4 

78.2 

4 

3 

1SRD  fOt  SI  = 

fc  6  3C4 

75  •  .* 

6 

J 

1  5.2 

6 

3 

CRPR |PP1L=  6304 

63C4 

7  5.2 

6 

3 

DPFR ,RSTP= 

3 

63C4 

7  5.2 

6 

3 

DCCA  *P  ST  F  - 

3  6304 

6  1.6 

6 

J 

C£CA*PS1P= 

J  6  304 

6  2.6 

4 

3 

7ERC 

f 

=  C  6304 

! 

62.6 

4 

3 

T  SPG 

» C£  S  T  =  fc 

63.2 

6 

3 

DEFG  *  SPCE  =  4 

6  4.4 

4 

J 

T£EX,SPCE*  6 

64.6 

3 

4 

1AM,CLAS  = 

3 

64.6 

3 

4 

1SRD,0PST= 

fc  8  4C  3 

65.2 

6 

3 

CELC  » SFC  E  =  4 

65.6 

6 

4 

65.6 

fc 

4 

CRPR  » PR  I C *  8403 

8403 

1 

65. e 

fc 

4 

DPFP,P$TP= 

a 

8403 

B 

85.6 

6 

4 

dp  t  c ,  cl  as  = 

66  •  * 

4 

3 

TEUP,SRCE=  t 

7«i 

66.2 

4 

3 

TETP,  *  0 

67.2 

6 

3 

C  AWR  ,CLAS= 

Cl 

67.2 

- 

3 

DPPR ,PS1F* 

2 

7e04 

J 

67.x 

6 

J 

CCCA  ,PSTP= 

4  7804 

1 

67.2 

6 

4 

D  N  PP  *  PS  T  F  = 

3 

8403 

j 

65.7 

6 

3 

DEDA ,PSTP= 

2  7  8C4 

56.2 

5 

3 

C  «WP  ,CLAS= 

I 

56.4 

C 

1 

CPFR  ,PS  TF  » 

3 

1104 

j 

T  ANT 

ARRIVAL  NEV*  TR  AN  SACT  1  CN 

DCCA 

ENC 

TC 

CAT  A 

ACCESS  QUEUE 

CEPG 

ENC 

CF 

e 

T  $R0 

SENDS  R E AC  MESSAGE 

OECA 

E  NO 

CF 

DATA 

ACCESS 

TEES 

ENC 

CF 

6 

DAPC 

ARRIVAL  OF  PEAC  MESSAGE 

CEPT 

ENO 

CF 

P  SG 

TRANSMISSION 

CELC 

ENC 

CE 

in 

n  JR  j 

SEND  REJECT 

TEPD 

ENC 

CF 

REAt 

PEASE 

TEUP 

END 

CF 

U 

DPPP 

PIMMUP  PR1CH11Y 

1SP0 

SENC 

EXEC  PPCGPAP 

T 


nvic  tCi«s  = 


UP»SPCE 


T  E  TP  , 


7604 


C  A*P  ,CLAS= 


7804 


LIE  GEPG 

ms 

GELD 

TEGP 


END  CP  EXEC  PRCGPAP 
ENC  CP  EXECUTION  PPA5E 
ENC  CP  UPOATE  CISTRIE. 
ENC  CF  UPCATE 


TETH  END  CP  TRANSACTION 
CAHR  ARRIVAL  CF  HP  ITE  N  E  5  S AGE 
TAPJ  ARRIVAL  CF  REJECT  AS  TP 
ORPR  RE  AC  PRIORITY 


1C0.C  1 


100  .c 


110. c 


0 


110.  c 


115.1 


116.1 


116.1 


1 16.9 


117.  9 


lie.s 


ns. 


119.5 


119.9 


119.9 


5  1AM,CIAS  = 


1SRD,CEST  = 


TSPC  tCE  S 1  = 


CARO»CLAS=  4  IC9C4 


ORPR  ,PRIC=  1C9CA 


IC9C4 


4^0^ 

CECA,RS1P=  ; 
IC9C4 

ICMC9CA  IC9C4 


TELPtSPCE* 


T  ANT 

ARRIVAL  NEW  TR AN S ACTION 

OCCA 

ENQ 

7  C 

DATA 

ACCESS  CUEUE 

CFPC 

ENT 

CF 

EXI 

1  SRC 

SEACS  PEA C  MESSAGE 

DECA 

END 

CF 

DATA 

ACCESS 

TEES 

END 

CF 

EW 

0  ARC 

APPIVAL  OF  PE  AC  PESSAGE 

CERT 

END 

CF 

MSG 

TRANSMISSION 

CELT 

EAT 

CF 

UP! 

0  SR  J 

SEND  REJEC1 

TERO 

END 

CF 

RE  AC 

PEASE 

TRIP 

ENC 

CF 

UP! 

OPPR 

MINIMUM  PRICPIIY 

TSPC 

SEND 

EXEC  PRCGRAV 

*  .11* 


s  s 

NT *  NAVE 


15.5A.A5  C*-  5-E2  FACE- 


MU.  TIPESTAPP 


TSM>. 


10CC  1 


ISM*.  =  C 

1302 

T  SM» *  =  C 

fc  AC  3 

CANW.l  b  = 


CANH  »CL  4  S  = 


CAN* »C  L  A  S  = 


1202 


EA03 


1000  1 


CEPG  ENC  CF  EXEC  PRCCPAP 
TEES  E*C  CF  EXECL  T f  C  N  PEASE 
CECO  END  CF  LlPDATE  DISTR1R. 

1FCP  ENC  CF  UPDATE 


TETR  END  CF  TRANSACT1CP 
CA*R  ARRIVAL  CF  tiPITE  PfcSSACE 

TARJ  ARRIVAL  CF  REJECT  AS  TP 

ORPR  READ  PRICRITY 


1*0.9 

C 

1 

DNFR,RSTF=  2 

_I!°L  . . . . j 

12C  •  9 

5 

1 

DCCA  ,RSTP  = 

2 

1  JOJ 

_ ^ 

121-3 

5 

l 

CECA,MS1P= 

2  1 3C2 

121  .<5 

5 

2 

C/SRC,  CLAS=  2  4  2  C  2 

1<t  1  .9 

C 

2 

CPPR  » PR  I C  =  42C2 

42C2 

121.  9 

5 

2 

CNFR.f'STF*  J 

4  202 

121  .9 

5 

2 

CQCAtRSTP= 

3 

4202  3 

129.7 

5 

2 

OECA  fRSlP  = 

3  42C2 

129  .9 

6 

1 

CAVnR,CLAS=  2 

129.9 

6 

1 

ONFR.RSTF*  2 

1  J02 

129.9 

6 

1 

CQCA  ,MSTP  = 

2 

1302 

129.9 

6 

4 

ONPP,MSTP=  3 

8403 

1  JO  .? 

/. 

2 

1  PRC  , 

=  0  4202  1 

13C.7 

2 

2 

T  SPG 

*CEST  =  5  ] 

131.1 

6 

l 

DEC  A.^STP* 

?  _  13C2  .  _ J 

131. 2 

5 

2 

DEFG,S»CE=  2  j 

1 J2  •  t 

2 

2 

1EEX,SPCE=  5  | 

133.2 

5 

2 

134.2 

2 

2 

134.2 

2 

2 

1ETR,  =  C  ] 

1 J5  .  t 

C 

2 

135.2 

t 

2 

DN  FR  »  NSTF  =  2 

■ 

135.2 

5 

2 

CQCAfRSlP= 

2 

L 

138.9 

R 

2 

OECA  ,RSTP= 

2  45C2  1 

1J5.6 

4 

6 

TANT,CIAS= 

4 

144.2 

6 

2 

C  AhP.  ,f  LAS  = 

144.2 

6 

2 

D*PR ,MSTP= 

2 

4SC2 

144.2 

6 

2 

COCA  ,RSTP= 

2  4  9  C  2 

144 

fc 

4 

DNFR,RSTF« 

3 

84C3 

14fc  .2 

6 

2 

CEC A,MSTP= 

2  4902 

181.3 

2 

7 

T  AM  ,CL  AS  = 

2 

181.3 

2 

7 

1SRC.CEST= 

5  154C2 

. . . 1 

T  ANT 

ARRIVAL  NEN  TRANSACTION 

DCD  A 

ENQ 

TC 

0  A  1 A 

ACCESS  QUEUE 

CEPG 

ENC 

CF 

1  SRC 

SENDS  READ  MESSAGE 

DECA 

ENC 

CF 

DATA 

ACCESS 

TEES 

END 

CF 

0  ARC 

ARRIVAL  OF  READ  MESSAGE 

DEPT 

ENC 

CF 

RSG 

TRANS M  ISSICN 

C  E  UC 

ENC 

CF 

OSRJ 

SEND  PEJECT 

TERD 

END 

CF 

RE  AC 

PHASE 

TELP 

ENC 

CF 

■t  P  PR 

RIMRLR  PPICFI1Y 

TSPC 

SENE 

EXEC  FRCGRAR 

SSSS2SS3SSS3 


KiEUE  CEPG  END  CF  EXEC  PRCGPAP  TETP  ENC  Cp  TRANSACTICN 

TEES  END  CF  EXECLTICN  PEASE  CAWR  APPIVAL  CE  WRITE  MESSAGE 

fclCN  CEUC  ENC  CF  UPC  ATE  CISTR18.  TARJ  APPIVAL  CF  REJECT  AS  TP 

TFIP  ENC  CF  UPCATE  CPPH  READ  PRICRITY 


E3 


* 


►SiPTCOlFlLB-A  C  l  S  S 


! 

8  a 

N  S  A  C 

1  1  c 

K  C  C 

F  F  l 

E  1  1  C 

K  T 

A  e  L  E 

p  c  pc 

C  .T 

F  IP  to 
CFC 

1PAKS.  CL 
KG  . 

ASS 

APR  . 

r  imf 

IS 

1  SP 

T  F 

C  .  T 

ecpp 

R  .  1 

KTP  .R 

C  F  C 

LVR 

C  F  C 

£ 

A 

It  .2 

78 

6  3 

C  . 

7  fc  .  2 

7  S  .2 

7S  .2 

C  . 

c  ( •  2 

1 1 

1 

2 

1  •  6 

1  3 

1  1 

0. 

U.6 

1A  .6 

no.o 

S  5.  A 

l^S.S 

12 

2 

2 

AS.  A 

AS 

A  2 

7C.5 

11Q.S 

12  l  .9 

12  l.S 

C. 

I  A  A.  2 

IA 

fc 

A 

1  IS. 5 

us 

ICS 

0. 

1  IS. 5 

12C.5 

18  7.2 

66.7 

211.1 

21 

A 

3 

fcA.e 

PA 

fc  A 

c. 

fc  A  •  fc 

65. fc 

167.2 

1CI.A 

220. C 

22 

6 

4 

13S  .  fc 

1  JC 

1  3A 

67.  J 

207.1 

2CS.  1 

2CS.  1 

C  . 

a  3  A 

A3 

. L._ 

l 

182. 0 

181 

l  Afc 

0. 

182. C 

182.0 

163.0 

C. 

1S1.2 

30 

1  .....i  . 

2 

181.3 

181 

15A 

0. 

16  1.3 

162.3 

2C2.3 

12C.C 

32C.7 

32 

|  S 

1 

1 

2  13. C 

2  12 

2  CC 

c  • 

2  13. C 

2  l  A  .  0 

3C2.3 

ee  .3 

323. A 

32 

!  ic 

1 

3C6.  2 

306 

2fc6 

7.2 

J  1  3  .A 

316.  A 

315. A 

c. 

33.:.  A 

33 

!  . ii~~~ 

L 

3  18.1 

3  18 

3  12 

3.3 

22  1  .A 

3  22  . A 

22  3. A 

c. 

3  A  2.  A 

3* 

1 

? 

{  K5/RTCQ1 

FILF  -  6 

C  I  S 

5 

j 

M 

R  6  A  C 

V*  R 

I  T  E 

l  C  G 

S 

j 


KCIlfc  5  KCE  fc 


TRAN# 

P  /to 

CL  S  I 

T  R  A  K  « 

p  /to 

CL  S 

1 

» 

2  | 

- 

p 

A 

3 

w 

4  | 

2 

to 

A 

l 

n 

2  I 

1 

to 

2 

2 

p 

?  1 

2 

to 

2 

2 

w 

2  I 

A 

P 

3 

8 

P 

l  I 

c 

P 

A 

5 

to 

A  | 

fc 

to 

1 

A 

w 

3  | 

A 

to 

■a 

6 

A  | 

fc 

to 

A 

7 

p 

2  1 

6 

0 

A 

8 

to 

1  1 

6 

to 

A 

9 

R 

1  | 

7 

to 

2 

7 

to 

2  1 

c 

to 

i 

9 

to 

1  1 

1  c 

to 

i 

10 

c 

1  I 

t  i 

to 

i 

10 

to 

1  | 

11 

p 

l  I 

11 

to 

1  1 

t 


'7 


AD-A117  990 
UNCLASSIFIED 


WEIZHANN  INST  OF  SCIENCE  REHOVOTH  (ISRAEL)  DEPT  OF  —ETC  F/G  9/2 
COMPARATIVE  PREDICTION  METHODOLOGY  FOR  DECENTRALIZED  DDBMS.(U) 

APR  82  M  MELMAN.  AF0SR-B1-01*»7 

EOARD-TR-82-11  NL 


I 


15.54.45  02-  5-82  PAGE 


1 


S  S 


1 

ROC 

C.T 

MPh 

CPC 

LVW 

CMC 

S  S  3  S  S  3  3 

HOC 

Q.T 

SfcP V  ICE 
T  1ME 

CCMPl 

TIME 

I 

C  . 

56.2 

110.0 

13.8 

4  1  .5 

86.2 

m 

II 81 

C  . 

117.5 

115.5 

2j 

MWp 

144.2 

C. 

26.3 

134.2 

r 

_ 

68.7 

217. 1 

217.1 

0. 

58.2 

207.1 

1| 

101.4 

220.0 

220.0 

0  . 

135  .4 

203  . C 

i 

awe 

wmm 

c . 

^6.5 

222.4 

m 

151.2 

302.3 

111.1 

124.4 

190.2 

120. C 

320.7 

320.7 

0. 

147.2 

310.7 

: 

ee.3 

323.4 

323  .4 

0  . 

1  16  .1 

313.4 

r 

0. 

JJJ.4 

JJ  J  .4 

o. 

d.  J  .J 

J2  1.4 

RESP 

TIME 

SYS  NCCE  PEJ 

TIME 

8  •  C 

41.5 

4 

106.3 

117.5 

2 

84.8 

56  .8 

2 

87.6 

56  .2 

4 

118.2 

135.4 

*3 

129.4  147.2  2 


ICO. 4  118.1 


15.2  30. 5 


1 


1 

* 

M528TOOI  ML1  -  ?  PISS 

I 

PUN  NO.  2  :  SIMFLE  MCDE L  ,  STATISTICS  CM V  ] 


T  NPljT  FUR  THE  PUN 


CLCeAL  P A  R  A  M  ET  EPS 


TIMfc  UNITS 

NUMBER  GF  CLASSES  IN  THE  SYSTEM 
VAX  NUM  CF  FRAGMENTS  PER  SET 
AVERAGE  LENGTH  CF  A  CCNTPCL  MESSAGE 
BATCH  SIZE 
CONFIDENCE  LEVEL 


MILLISECONDS 

4 


C 

C. 

25 

C, 


50  (UNITS  OF  TIME* 
SO 


MAGS 

TRACE  FLAG 
TRACE  DRIVEN  MAG 
l  CG  FLAG 

PROTOCOL  NUMBERS 

CLASS  1  2  A  4 

PROTOCOL  1231 


0 

0 

0 


GCNFUCT  CLASS  MATRIX 

T=  =  =-rrs=  =  ss=  =  r=:s=ssss=: 


l 

£ 

3 

4 


I  2  i 

COO 
1  C  T 

COO 
GOO 


4 

c 

0 

1 

0 


NODE  CHARACTERIZATION 


NQPF  .  ID 

F  R  0  S 
TYPE 

CLASS 

TRAN 

INT 

ARR 

(EXPO  * 

s 

t 

E 

0 

AV 

PROG. 

LENGTH 

(EXPO* 

U)LL>iJJO 

CAT  A 
AC.CES 
TIME 
(EXPCI 

S 

E 

E 

D 

TIME 

CUT 

(FIX* 

Dl  1 

PC  R 

F  LG 

PEAC 
TIME 
ST  AMI 
PELT 

1 

TM 

T 

100.0 

4 

2.0 

5 

100.0 

1 

.200 

2 

TM 

2 

100.0 

6 

2.0 

7 

10C.0 

I 

.2  CO 

3 

TMI 

3 

ICO.O 

t 

2.  C 

5 

IOC.C 

4 

TM 

4 

T  00 . 0 

TO 

2.0 

T  1 

ICO.O 

T 

.200 

5 

CM 

3.0 

2 

1CC.C 

t 

DM 

3.0 

3 

100. 0 

A 


\ 

s  s 

,  STATISTICS  CMY 


1F.36.2H  02-  5-62 


OF  TIME* 


CUT 

IFIXI 

100.0 
iOC.O 
100.0 
TOO  .0 
1C0.0 
100.0 


on 

PCR 

FIG 


l 


PE  AC 
IFF 
STAMP 
05:11  A 


.2000 


2CC0 


\- 


1 

PAGE-  2 


f 


1 


^ooo 


M52BTC01 


FILF 


2 


HISS 


SYSTEM  PERFORM ANC 6  RESULTS 

SlMtlATICN  TIME  =  ICOQOO.O  UMTS 


T  M  NCDE  STATISTICS 

=s==ss=ss===s==.ss 


Ncr 

IC 

NUM 

TRAN 

COMP 

TP  ANS 

T*  C. 

1  IMF 

AVG  « 

WAIT  . 

TRANS 

*  CF 

RE  JEC 
TRANS 

TW 

UTIL. 

AVG 

RFSPQ 

TIME 

RESPC 

1  IM! 

STD 

, 

S*n 

1  4  .C  TO 

.137 

C. 

.309 

4b. 983 

86,135 

2 

729 

38.4S5 

•  3  80 

26 . 180 

•  573 

1C9. 1C4 

47.36  c 

3 

c  2  C 

I  1  .  1 5  5 

.32  1 

1C. 553 

.*21 

81.8C2 

41.C73 

94  3 

6.E71 

•  06  5 

C  . 

.  4  TO 

/S.4C 3 

3  J.E  IS 

CM 

NCCF  STAI 1ST  ICS 

R  E  AC 

WR  I  TF 

NCO 

C  MQ 

C  MO 

rc 

T  IME 

TIME 

5 

38.581 

7  .57 C 

26.65 3 

T  .647 

GLOBAL  STATISTICS 

NCVHFR  CF  TRANSACT  !  t  NS  ARRIVED  IN  SYSTFM 
NUMBER  CF  TRANSACT  ICNS  PRCCESSEC  ( AFTER  WRITES* 

MJMPER  CF  TRANSACTICMS  REJECTEC 

NUMBER  OF  MESSAGES  SENT  PER  TRANSACT  ICN  ,  AVG  (INC.  NW * 
AVG.  SY  S  TER  TIME  PER  TRANSACT  ICN 

AVG.  TRANSMISSION  TIME  PER  TRANSACTION  ( NOT  INC.  NW> 
AVG.  RESFNSE  TIME  PEP  TRANSACTICN 


4/)»CD 


16. 40. AT  02-  5-82 


ESPC 

IPE 

TC 

e  ATCF 

AVG 

SIC 

PfcLAT 

FREC  I 

IN  t 

CORK 

NU* 

CF 

BATCHES 

46,135 

17.161 

IC.222 

HI 

• 

1 

36 

47.36-<: 

11.015 

3.185 

.020 

25 

41  ,C73 

12.012 

4.135 

-.137 

36 

3  J.6  IS 

10.313 

5.802 

-  •  C  54 

37 

3535 

3562 

367 

8.5858 

89.0241 

UMTS 

18.6173 

UNITS 

63.7858 

UMTS 

PACE-  3 


THF  RUN  NEECEC 


59.96  CPU  SECCNCS 


